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