[git-p4: depot-paths = "//depot/": change = 893]replace/f588c97ebcad1ddd2494fc2a4ae17a592b597d09
@@ -1,812 +0,0 @@ | |||||
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] | |||||
@@ -1,348 +0,0 @@ | |||||
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 |
@@ -1,928 +0,0 @@ | |||||
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 |
@@ -1,17 +0,0 @@ | |||||
<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> |
@@ -1,17 +0,0 @@ | |||||
<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> |
@@ -1,477 +0,0 @@ | |||||
<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> | |||||
@@ -1,170 +0,0 @@ | |||||
<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> |
@@ -1,405 +0,0 @@ | |||||
<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> | |||||
@@ -1,718 +0,0 @@ | |||||
<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> | |||||
@@ -1,168 +0,0 @@ | |||||
<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> |
@@ -1,48 +0,0 @@ | |||||
<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> |
@@ -1,146 +0,0 @@ | |||||
<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> |
@@ -1,347 +0,0 @@ | |||||
<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> |
@@ -0,0 +1,376 @@ | |||||
#!/usr/bin/env python | |||||
from cdvdread import * | |||||
import itertools | |||||
import sys | |||||
class DVDReadError(Exception): | |||||
pass | |||||
__all__ = [ 'DVD', | |||||
] | |||||
dvd_domain_valid = [ DVD_READ_INFO_FILE, DVD_READ_INFO_BACKUP_FILE, | |||||
DVD_READ_MENU_VOBS, DVD_READ_TITLE_VOBS, ] | |||||
dvd_domain_valid_names = [ 'DVD_READ_INFO_FILE', 'DVD_READ_INFO_BACKUP_FILE', | |||||
'DVD_READ_MENU_VOBS', 'DVD_READ_TITLE_VOBS', ] | |||||
try: | |||||
dvd_domain_valid = set(dvd_domain_valid) | |||||
except NameError: | |||||
pass | |||||
# Make sure the library matches what we are compiled for | |||||
assert DVDREAD_VERSION == DVDVersion() | |||||
DVDInit() | |||||
def attribreprlist(obj, attrs): | |||||
return map(lambda x, y = obj: '%s: %s' % (x, repr(getattr(y, x))), itertools.ifilter(lambda x, y = obj: hasattr(y, x), attrs)) | |||||
def bcdtoint(bcd): | |||||
base = 1 | |||||
ret = 0 | |||||
while bcd: | |||||
assert bcd % 16 < 10, 'invalid bcd digit in: %#x' % bcd | |||||
ret += bcd % 16 * base | |||||
base *= 10 | |||||
bcd /= 16 | |||||
return ret | |||||
class DVDTime: | |||||
'''Should be able to perform math, though until I get the frame rate bit info, I really can't do anything about it.''' | |||||
__slots__ = [ '_hour', '_minute', '_second', '_frame_u', '_rate', '_seconds', '_frames' ] | |||||
hour = property(lambda x: x._hour) | |||||
minute = property(lambda x: x._minute) | |||||
second = property(lambda x: x._second) | |||||
frame = property(lambda x: x._frame) | |||||
rate = property(lambda x: x._rate) | |||||
ratestr = property(lambda x: x._ratestr) | |||||
seconds = property(lambda x: x._seconds) | |||||
frames = property(lambda x: x._frames) | |||||
def __init__(self, dt): | |||||
'''Take a dvd time object that has the attributes hour, minute, second and frame_u (bits 6-7 are frame rate, bits 0-5 is frame.''' | |||||
self._hour = bcdtoint(dt.hour) | |||||
self._minute = bcdtoint(dt.minute) | |||||
self._second = bcdtoint(dt.second) | |||||
self._frame = bcdtoint(dt.frame_u & 0x3f) | |||||
fr = (dt.frame_u & 0xc0) >> 6 | |||||
assert fr in (1, 3), 'Unknown frame rate: %d' % fr | |||||
self._rate = [-1, 25.0, -1, 29.97 ][fr] | |||||
self._ratestr = [-1, '25.0', -1, '29.97' ][fr] | |||||
self._seconds = (self._hour * 60 + self._minute) * 60 + self._second + self._frame / self._rate | |||||
self._frames = self._seconds * self._rate | |||||
def __int__(self): | |||||
return int(self._seconds) | |||||
def __float__(self): | |||||
return self._seconds | |||||
def __repr__(self): | |||||
return '%s@%s' % (str(self), self.ratestr) | |||||
def hhmmss(self): | |||||
return '%02d:%02d:%02d' % (self._hour, self._minute, self._second) | |||||
def __str__(self): | |||||
return '%02d:%02d:%02d.%02d' % (self._hour, self._minute, self._second, self._frame) | |||||
class audio_attr: | |||||
pos = property(lambda x: x._pos) | |||||
lang = property(lambda x: x._lang) | |||||
audio_format = property(lambda x: x._audio_format) | |||||
lang_type = property(lambda x: x._lang_type) | |||||
application_mode = property(lambda x: x._application_mode) | |||||
quantization = property(lambda x: x._quantization) | |||||
sample_frequency = property(lambda x: x._sample_frequency) | |||||
channels = property(lambda x: x._channels) | |||||
def __init__(self, audioattr, pos): | |||||
self._pos = pos | |||||
lc = audioattr.lang_code | |||||
self._lang = chr(lc>>8) + chr(lc & 255) | |||||
self._audio_format = audioattr.audio_format | |||||
self._lang_type = audioattr.lang_type | |||||
self._application_mode = audioattr.application_mode | |||||
self._quantization = audioattr.quantization | |||||
self._sample_frequency = audioattr.sample_frequency | |||||
self._channels = audioattr.channels | |||||
def __repr__(self): | |||||
v = [ 'pos', 'lang', 'sample_frequency', 'channels' ] | |||||
return '<audio_attr: %s>' % ', '.join(attribreprlist(self, v)) | |||||
class IFO: | |||||
ifodata = None # __del__ | |||||
# VMGI | |||||
vmgi_mat = property(lambda x: x.ifodata.vmgi_mat) | |||||
tt_srpt = property(lambda x: x.ifodata.tt_srpt) | |||||
first_play_pgc = property(lambda x: x.ifodata.first_play_pgc) | |||||
ptl_mait = property(lambda x: x.ifodata.ptl_mait) | |||||
vts_atrt = property(lambda x: x.ifodata.vts_atrt) | |||||
txtdt_mgi = property(lambda x: x.ifodata.txtdt_mgi) | |||||
# Common | |||||
pgci_ut = property(lambda x: x.ifodata.pgci_ut) | |||||
menu_c_adt = property(lambda x: x.ifodata.menu_c_adt) | |||||
menu_vobu_admap = property(lambda x: x.ifodata.menu_vobu_admap) | |||||
# VTSI | |||||
vtsi_mat = property(lambda x: x.ifodata.vtsi_mat) | |||||
vts_ptt_srpt = property(lambda x: x.ifodata.vts_ptt_srpt) | |||||
vts_pgcit = property(lambda x: x.ifodata.vts_pgcit) | |||||
vts_tmapt = property(lambda x: x.ifodata.vts_tmapt) | |||||
vts_c_adt = property(lambda x: x.ifodata.vts_c_adt) | |||||
vts_vobu_admap = property(lambda x: x.ifodata.vts_vobu_admap) | |||||
def __init__(self, dvd, i): | |||||
self.ifodata = ifoOpen(dvd.dvdreader, i) | |||||
self.dvd = dvd | |||||
self.audio = {} | |||||
if i: | |||||
# we are a VTS, populate some data | |||||
for i in xrange(self.vtsi_mat.nr_of_vts_audio_streams): | |||||
j = audio_attr(audio_attr_getitem( | |||||
self.vtsi_mat.vts_audio_attr, i), i) | |||||
self.audio[j.lang] = j | |||||
def __del__(self): | |||||
if self.ifodata: | |||||
ifoClose(self.ifodata) | |||||
self.ifodata = None | |||||
class DVDProgram: | |||||
'''This represents a chapter in a title.''' | |||||
time = property(lambda x: x._time) | |||||
size = property(lambda x: x._size) | |||||
def __init__(self, dvdtitle, cpb): | |||||
self.dvdtitle = dvdtitle | |||||
self.cpb = cpb | |||||
self._time = DVDTime(self.cpb.playback_time) | |||||
self._size = (self.cpb.last_sector - self.cpb.first_sector + | |||||
1) * self.dvdtitle.dvd.blocksize | |||||
def blockiter(self, blkcnt = 16): | |||||
# last isn't inclusive | |||||
last = self.cpb.last_sector + 1 | |||||
for i in xrange(self.cpb.first_sector, last, blkcnt): | |||||
yield self.dvdtitle.vob.pread(min(blkcnt, last - i), i) | |||||
def __iter__(self): | |||||
blklen = self.dvdtitle.dvd.blocksize | |||||
for i in self.blockiter(): | |||||
for j in xrange(0, len(i), blklen): | |||||
yield i[j:j + blklen] | |||||
def __repr__(self): | |||||
return '<DVDProgram: Time: %s>' % \ | |||||
DVDTime(self.cpb.playback_time) | |||||
class DVDFile: | |||||
dvdfile = None # __del__ | |||||
def __init__(self, dvd, vts, dom): | |||||
assert dom in dvd_domain_valid, 'Must be one of: %s' % `dvd_domain_valid_names` | |||||
self.dvdfile = DVDOpenFile(dvd.dvdreader, vts, dom) | |||||
if self.dvdfile is None: | |||||
raise ValueError, 'DVD file (%d, %d) does not exist' % (vts, dom) | |||||
self.vts = vts | |||||
self.dom = dom | |||||
self.dvd = dvd | |||||
def __del__(self): | |||||
if self.dvdfile: | |||||
DVDCloseFile(self.dvdfile) | |||||
self.dvdfile = None | |||||
def pread(self, nblocks, blkoff): | |||||
assert self.dom in (DVD_READ_MENU_VOBS, DVD_READ_TITLE_VOBS), \ | |||||
'Must be of type DVD_READ_MENU_VOBS or DVD_READ_TITLE_VOBS.' | |||||
buf = malloc_void(nblocks * self.dvd.blocksize) | |||||
assert buf, 'buf allocation failed' | |||||
try: | |||||
b = DVDReadBlocks(self.dvdfile, blkoff, nblocks, | |||||
voidptr_to_ucharptr(buf)) | |||||
ret = cdata(buf, b * self.dvd.blocksize) | |||||
return ret | |||||
finally: | |||||
free_void(buf) | |||||
def seek(self, pos, whence = 0): | |||||
assert whence == 0, 'Only SEEK_SET is supported' | |||||
return DVDFileSeek(self.dvdfile, pos) | |||||
def read(self, *args): | |||||
if len(args) == 0: | |||||
#read it all | |||||
res = [] | |||||
data = 1 | |||||
while data: | |||||
data = self.read(65536) | |||||
res.append(data) | |||||
return ''.join(res) | |||||
assert len(args) == 1, 'Only takes one argument: count' | |||||
buf = malloc_void(*args) | |||||
assert buf, 'buf allocation failed' | |||||
try: | |||||
b = DVDReadBytes(self.dvdfile, buf, *args) | |||||
ret = cdata(buf, b) | |||||
return ret | |||||
finally: | |||||
free_void(buf) | |||||
def __len__(self): | |||||
return DVDFileSize(self.dvdfile) * self.dvd.blocksize | |||||
class DVDTitle: | |||||
'''This is a title.''' | |||||
time = property(lambda x: x._time) | |||||
audio = property(lambda x: x.vts.audio) | |||||
def selectaudio(self, lang): | |||||
if isinstance(lang, basestring): | |||||
lang = [ lang ] | |||||
for l in lang: | |||||
try: | |||||
return self.audio[l] | |||||
except KeyError: | |||||
pass | |||||
for l in self.lang: | |||||
if l.pos == 0: | |||||
return l | |||||
def __init__(self, dvd, vts, ttu): | |||||
'''dvd is of class DVD, vts is the vts number one based, and ttu is the sub-vts one based.''' | |||||
self.dvd = dvd | |||||
self.vts = dvd.getifo(vts) | |||||
assert ttu > 0 and ttu <= self.vts.vts_pgcit.nr_of_pgci_srp | |||||
self.pgci = pgci_srp_getitem(self.vts.vts_pgcit.pgci_srp, ttu - 1).pgc | |||||
self.ttu = ttu | |||||
self.vob = DVDFile(dvd, vts, DVD_READ_TITLE_VOBS) | |||||
self._time = DVDTime(self.pgci.playback_time) | |||||
def __len__(self): | |||||
return self.pgci.nr_of_programs | |||||
def __getitem__(self, key): | |||||
if key < 0 or key >= len(self): | |||||
raise IndexError | |||||
assert key < self.pgci.nr_of_cells, \ | |||||
'key cannot be mapped from program to cell(%d)' % \ | |||||
(self.pgci.nr_of_programs, self.pgci.nr_of_cells) | |||||
# cell is stored starting at 1, adjust to 0 | |||||
cell = uchar_getitem(self.pgci.program_map, key) - 1 | |||||
cell_playback = cell_playback_getitem(self.pgci.cell_playback, | |||||
cell) | |||||
return DVDProgram(self, cell_playback) | |||||
def __repr__(self): | |||||
return '<DVDTitle: Chapters: %d, Time: %s>' % (len(self), self.time) | |||||
def data(self): | |||||
'''Returns the data in blocks for the title.''' | |||||
for i in self: | |||||
for j in i: | |||||
yield j | |||||
class discid: | |||||
__slots__ = [ '_discid' ] | |||||
discid = property(lambda x: x._discid) | |||||
def __init__(self, discid): | |||||
self._discid = discid | |||||
def __str__(self): | |||||
return ''.join(map(lambda x: '%02x' % ord(x), self.discid)) | |||||
def __repr__(self): | |||||
return '<DVD ID: %s>' % ''.join(map(lambda x: '%02x' % ord(x), self.discid)) | |||||
class DVD: | |||||
'''Children must keep a reference to this object so that we don't close | |||||
the dvd before all the files are closed. This does mean children will | |||||
need to know the insides of this class, but that is fine since it's all | |||||
internal to this implementation anyways.''' | |||||
dvdreader = None # __del__ | |||||
blocksize = property(lambda x: x._blocksize) | |||||
volid = property(lambda x: x._volid) | |||||
volsetid = property(lambda x: x._volsetid) | |||||
cache = property(lambda x: DVDUDFCacheLevel(x.dvdreader, -1), lambda x, y: DVDUDFCacheLevel(x.dvdreader, bool(y))) | |||||
def __init__(self, path): | |||||
self.dvdreader = DVDOpen(path) | |||||
if self.dvdreader is None: | |||||
raise ValueError, 'path is not a DVD' | |||||
self._discidval = None | |||||
# XXX - this may need to be dynamicly probed | |||||
self._blocksize = 2048 | |||||
# pull in the volid and volsetid | |||||
r, volid, volsetid = DVDUDFVolumeInfo(self.dvdreader, 32, 128) | |||||
if r != 0: | |||||
self._volid = volid[:volid.index('\x00')].decode('latin-1') | |||||
self._volsetid = volsetid | |||||
else: | |||||
# Fall back to ISO, shouldn't happen as all | |||||
# DVD's are UDF | |||||
r, volid, voldsetid = DVDISOVolumeInfo(self.dvdreader, 33, 128) | |||||
assert r == 0 | |||||
# Techinically more restrictive [A-Z0-9_] | |||||
self._volid = volid[:volid.index('\x00')].decode('ascii') | |||||
self._volsetid = volsetid | |||||
self.vmg = self.getifo(0) | |||||
self._len = self.vmg.tt_srpt.nr_of_srpts | |||||
def __del__(self): | |||||
if self.dvdreader: | |||||
DVDClose(self.dvdreader) | |||||
self.dvdreader = None | |||||
def getifo(self, i): | |||||
return IFO(self, i) | |||||
def _discid(self): | |||||
if self._discidval is not None: | |||||
return self._discidval | |||||
buf = malloc_void(16) | |||||
assert buf, 'buf allocation failed' | |||||
try: | |||||
r = DVDDiscID(self.dvdreader, voidptr_to_ucharptr(buf)) | |||||
if r == -1: | |||||
raise DVDReadError, "failed to compute disc id" | |||||
self._discidval = discid(cdata(buf, 16)) | |||||
return self._discidval | |||||
finally: | |||||
free_void(buf) | |||||
discid = property(_discid) | |||||
def __len__(self): | |||||
return self._len | |||||
def __getitem__(self, key): | |||||
if key < 0 or key >= len(self): | |||||
raise IndexError | |||||
title = title_info_getitem(self.vmg.tt_srpt.title, key) | |||||
return DVDTitle(self, title.title_set_nr, title.vts_ttn) | |||||
def __repr__(self): | |||||
return '<DVD: %s, ID: %s, Titles: %s>' % (self._volid, self.discid, len(self)) |
@@ -0,0 +1,84 @@ | |||||
// File : dvdread.i | |||||
%module cdvdread | |||||
%include "typemaps.i" | |||||
%include "stdint.i" | |||||
%include "cmalloc.i" | |||||
%include "carrays.i" | |||||
%include "cdata.i" | |||||
%allocators(void); | |||||
%include "cpointer.i" | |||||
%pointer_cast(void *, unsigned char *, voidptr_to_ucharptr); | |||||
typedef long ssize_t; | |||||
typedef long long off_t; | |||||
%{ | |||||
#include "dvdread/dvd_reader.h" | |||||
#include "dvdread/ifo_read.h" | |||||
#include "dvdread/nav_read.h" | |||||
%} | |||||
%typemap (in,numinputs=1) (unsigned char *uc128, unsigned int uc128) (unsigned char tempa[128], int tempb) { | |||||
$1 = tempa; | |||||
$2 = tempb = PyInt_AsLong($input); | |||||
if (tempb <= 0 || tempb > 128) { | |||||
PyErr_SetString(PyExc_ValueError, "int out of range (0,128]"); | |||||
return NULL; | |||||
} | |||||
} | |||||
%typemap (argout) (unsigned char *uc128, unsigned int uc128) { | |||||
$result = SWIG_Python_AppendOutput($result, PyString_FromStringAndSize(tempa$argnum, tempb$argnum)); | |||||
} | |||||
%typemap (in,numinputs=1) (char *c33, unsigned int c33) (char tempa[33], int tempb) { | |||||
$1 = tempa; | |||||
$2 = tempb = PyInt_AsLong($input); | |||||
if (tempb <= 0 || tempb > 33) { | |||||
PyErr_SetString(PyExc_ValueError, "int out of range (0,33]"); | |||||
return NULL; | |||||
} | |||||
} | |||||
%typemap (argout) (char *c33, unsigned int c33) { | |||||
$result = SWIG_Python_AppendOutput($result, PyString_FromStringAndSize(tempa$argnum, tempb$argnum)); | |||||
} | |||||
int DVDUDFVolumeInfo( dvd_reader_t *, char *c33, unsigned int c33, | |||||
unsigned char *uc128, unsigned int uc128); | |||||
int DVDISOVolumeInfo( dvd_reader_t *, char *c33, unsigned int c33, | |||||
unsigned char *uc128, unsigned int uc128); | |||||
/* Clear them */ | |||||
%typemap (in,numinputs=1) (unsigned char *uc128, unsigned int uc128) (unsigned char tempa[128], int tempb); | |||||
%typemap (argout) (unsigned char *uc128, unsigned int uc128); | |||||
%typemap (in,numinputs=1) (char *c33, unsigned int c33) (char tempa[33], int tempb); | |||||
%typemap (argout) (char *c33, unsigned int c33); | |||||
%include dvdread/dvd_reader.h | |||||
%include dvdread/ifo_read.h | |||||
%include <stdint.h> | |||||
%include dvdread/ifo_types.h | |||||
%array_functions(audio_attr_t, audio_attr) | |||||
%array_functions(cell_playback_t, cell_playback) | |||||
%array_functions(cell_position_t, cell_position) | |||||
%array_functions(map_ent_t, map_ent) | |||||
%array_functions(pgc_program_map_t, pgc_program_map) | |||||
%array_functions(pgci_lu_t, pgci_lu) | |||||
%array_functions(pgci_srp_t, pgci_srp) | |||||
%array_functions(ptt_info_t, ptt_info) | |||||
%array_functions(subp_attr_t, subp_attr) | |||||
%array_functions(title_info_t, title_info) | |||||
%array_functions(ttu_t, ttu) | |||||
%array_functions(txtdt_lu_t, txtdt_lu) | |||||
%array_functions(unsigned char, uchar) | |||||
%array_functions(vm_cmd_t, vm_cmd) | |||||
%array_functions(vts_attributes_t, vts_attributes) | |||||
%array_functions(vts_tmap_t, vts_tmap) | |||||
%include dvdread/nav_read.h |
@@ -0,0 +1,23 @@ | |||||
#!/usr/bin/env python | |||||
from distutils.core import setup, Extension | |||||
import os.path | |||||
dvdreaddir = '/opt/local' | |||||
dvdreaddirinc = os.path.join(dvdreaddir, 'include') | |||||
dvdreaddirlib = os.path.join(dvdreaddir, 'lib') | |||||
setup(name = "pydvdread", version = "0.1", | |||||
description = "Python libdvdread interface", | |||||
author = "John-Mark Gurney", | |||||
author_email = "gurney_j@resnet.uoregon.edu", | |||||
packages = [ 'pydvdread' ], | |||||
package_dir = { 'pydvdread': '.' }, | |||||
ext_package = "pydvdread", | |||||
ext_modules = [ Extension("_cdvdread", [ "dvdread.i" ], | |||||
swig_opts = [ '-I/usr/include', '-I%s' % dvdreaddirinc ], | |||||
include_dirs = [ dvdreaddirinc, '/usr/include' ], | |||||
library_dirs = [ dvdreaddirlib, ], | |||||
libraries = [ 'dvdread' ]), | |||||
] | |||||
) |
@@ -0,0 +1,82 @@ | |||||
#!/usr/bin/env python | |||||
import pydvdread | |||||
import sys | |||||
def bcdtoint(bcd): | |||||
base = 1 | |||||
ret = 0 | |||||
while bcd: | |||||
assert bcd % 16 < 10, 'invalid bcd digit in: %#x' % bcd | |||||
ret += bcd % 16 * base | |||||
base *= 10 | |||||
bcd /= 16 | |||||
return ret | |||||
def strdvdtime(tobj): | |||||
return '%x:%02x:%02x.%02x' % (tobj.hour, tobj.minute, tobj.second, | |||||
tobj.frame_u & 0x3f) | |||||
def dumppgc(j): | |||||
print 'nr_of_progs:', j.nr_of_programs | |||||
print 'nr_of_cells:', j.nr_of_cells | |||||
print 'time:', strdvdtime(j.playback_time) | |||||
for k in range(j.nr_of_programs): | |||||
print 'program_map[%d]:' % k, pydvdread.uchar_getitem( | |||||
j.program_map, k) | |||||
for k in range(j.nr_of_cells): | |||||
l = pydvdread.cell_playback_getitem(j.cell_playback, k) | |||||
print 'cell_playback[%d]:' % k, '%d-%d' % (l.first_sector, | |||||
l.last_sector), strdvdtime(l.playback_time) | |||||
try: | |||||
dvd = pydvdread.DVD('/dev/null') | |||||
except ValueError: | |||||
pass | |||||
except: | |||||
assert 0, 'Failed to fail.' | |||||
dvd = pydvdread.DVD('/dev/rdisk1') | |||||
print dvd, ', '.join(map(repr, dvd)) | |||||
try: | |||||
print `dvd[(5, 5)]` | |||||
except IndexError: | |||||
pass | |||||
except: | |||||
assert 0, 'Failed to fail.' | |||||
print 'vmg' | |||||
ifo = dvd.getifo(0) | |||||
assert ifo.txtdt_mgi is None | |||||
print 'ifo:', `ifo` | |||||
print '# vts:', ifo.vmgi_mat.vmg_nr_of_title_sets | |||||
print 'provider:', `ifo.vmgi_mat.provider_identifier` | |||||
print 'nr_of_srpts:', ifo.tt_srpt.nr_of_srpts | |||||
for i in range(ifo.tt_srpt.nr_of_srpts): | |||||
print `ifo.tt_srpt.title` | |||||
j = pydvdread.title_info_getitem(ifo.tt_srpt.title, i) | |||||
print 'playbacktype:', j.pb_ty.multi_or_random_pgc_title, j.pb_ty.jlc_exists_in_cell_cmd, j.pb_ty.jlc_exists_in_prepost_cmd, j.pb_ty.jlc_exists_in_button_cmd, j.pb_ty.jlc_exists_in_tt_dom, j.pb_ty.chapter_search_or_play, j.pb_ty.title_or_time_play | |||||
print '# angles:', j.nr_of_angles | |||||
print '# ptts:', j.nr_of_ptts | |||||
print 'parental id:', j.parental_id | |||||
print 'title set #:', j.title_set_nr | |||||
print 'vts ttn:', j.vts_ttn | |||||
for ifonum in range(ifo.vmgi_mat.vmg_nr_of_title_sets): | |||||
print 'vts' | |||||
ifo = dvd.getifo(1 + ifonum) | |||||
print 'ifo:', `ifo` | |||||
print dir(ifo) | |||||
print '# of srpts:', ifo.vts_ptt_srpt.nr_of_srpts | |||||
for i in range(ifo.vts_ptt_srpt.nr_of_srpts): | |||||
print 'title #:', i | |||||
j = pydvdread.ttu_getitem(ifo.vts_ptt_srpt.title, i) | |||||
print '# of ptts:', j.nr_of_ptts | |||||
for i in range(j.nr_of_ptts): | |||||
k = pydvdread.ptt_info_getitem(j.ptt, i) | |||||
print 'pgcn:', k.pgcn | |||||
print 'pgn:', k.pgn | |||||
print 'pgc:', `ifo.vts_pgcit.nr_of_pgci_srp` | |||||
for i in range(ifo.vts_pgcit.nr_of_pgci_srp): | |||||
dumppgc(pydvdread.pgci_srp_getitem(ifo.vts_pgcit.pgci_srp, i).pgc) |