attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v = "urn:schemas-microsoft-com:vml" xmlns:o = "urn:schemas-microsoft-com:office:office" xmlns:w = "urn:schemas-microsoft-com:office:word" xmlns:st1 = "urn:schemas-microsoft-com:office:smarttags"><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> <META content="MSHTML 6.00.2800.1528" name=GENERATOR><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PostalCode"></o:SmartTagType><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="State"></o:SmartTagType><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"></o:SmartTagType><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="Street"></o:SmartTagType><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place"></o:SmartTagType><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="address"></o:SmartTagType><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="PersonName"></o:SmartTagType> <STYLE>  </STYLE> </HEAD> <BODY lang=EN-US vLink=purple link=blue> <DIV>Hi Stuart,</DIV> <DIV> </DIV> <DIV>I'm forwarding this thread to the WIMS WG list, because these were</DIV> <DIV>comments during a Formal Vote, and Bill put them on the agenda for</DIV> <DIV>tomorrow's WIMS telecon.</DIV> <DIV> </DIV> <DIV>All - Stuart's experience reading this spec and lacking tools to read the</DIV> <DIV>schema (formatted) indicate that we need to:</DIV> <DIV> </DIV> <DIV>(a) do more work on our specs;</DIV> <DIV>(b) find better tools; and </DIV> <DIV>(c) discuss our migration from binary protocols (eg, IPP) to XML </DIV> <DIV>     schema based protocols - which are excruciatingly verbose in</DIV> <DIV>     schemas and completely opaque (untyped) in instances.</DIV> <DIV> </DIV> <DIV>Cheers,</DIV> <DIV>- Ira</DIV> <DIV> </DIV> Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221  Grand Marais, MI  49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left>-----Original Message----- From: McDonald, Ira Sent: Saturday, April 22, 2006 2:09 PM To: 'Stuart Rowley'; wamwagner@comcast.net; Harry Lewis; McDonald, Ira Subject: RE: [more replies to Stuart] WIMS Protocol Spec Questions </DIV> <DIV>Hi Stuart,</DIV> <DIV> </DIV> <DIV>More replies inline below as <ira-2></DIV> <DIV> </DIV> <DIV>Cheers,</DIV> <DIV>- Ira</DIV> <DIV> </DIV> Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221  Grand Marais, MI  49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com <BLOCKQUOTE dir=ltr style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left>-----Original Message----- From: Stuart Rowley [mailto:Stuart.Rowley@ktd-kyocera.com] Sent: Friday, April 21, 2006 5:53 PM To: McDonald, Ira; wamwagner@comcast.net; Harry Lewis Subject: RE: WIMS Protocol Spec Questions </DIV> <DIV class=Section1> Hi Ira,<o:p></o:p> <o:p> </o:p> Thanks for your quick comments (and for not chewing me out for waiting so long to comment).<o:p></o:p> <o:p> </o:p> I included some responses to your comments as SR> bla bla<o:p></o:p> <o:p> </o:p> It seems that the main problem is that I did not review the schema. I tried, but they may as well be in hieroglyphics when viewed in Word or Notepad. I do not have XMLSpy (it is $499). I tried downloading XMLFox, but it was just no help at all. I guess it would have made considerably more sense if I had been able to adequately review the schema. Can you suggest a way for me to review the schema?<o:p></o:p> <o:p> </o:p> Best regards,<o:p></o:p> <o:p> </o:p> Stuart<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <DIV> <DIV class=MsoNormal style="TEXT-ALIGN: center" align=center> <HR tabIndex=-1 align=center width="100%" SIZE=2> </DIV> From: McDonald, Ira [mailto:imcdonald@sharplabs.com] Sent: Friday, April 21, 2006 1:24 PM To: <st1:PersonName w:st="on">Stuart Rowley</st1:PersonName>; wamwagner@comcast.net; Harry Lewis Subject: RE: WIMS Protocol Spec Questions<o:p></o:p></DIV> <o:p> </o:p> <DIV> Hi Stuart,<o:p></o:p></DIV> <DIV>  <o:p></o:p></DIV> <DIV> By sheer luck, I just logged on to check my email - so below are some replies inline.<o:p></o:p></DIV> <DIV>  <o:p></o:p></DIV> <DIV> To avoid further confusion, read the operation definitions and the _schema_ first and then look at the less rigorous and informative examples and diagrams.<o:p></o:p></DIV> <DIV>  <o:p></o:p></DIV> <DIV> Cheers,<o:p></o:p></DIV> <DIV> - Ira<o:p></o:p></DIV> <DIV>  <o:p></o:p></DIV> <DIV>  <o:p></o:p></DIV> Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc <st1:address w:st="on"><st1:Street w:st="on">PO Box</st1:Street> 221</st1:address>  Grand <st1:place w:st="on"><st1:City w:st="on">Marais</st1:City>, <st1:State w:st="on">MI</st1:State>  <st1:PostalCode w:st="on">49839</st1:PostalCode></st1:place> phone: +1-906-494-2434 email: imcdonald@sharplabs.com <o:p></o:p> <BLOCKQUOTE style="BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: medium none; PADDING-LEFT: 4pt; PADDING-BOTTOM: 0in; MARGIN: 5pt 0in 5pt 3.75pt; BORDER-LEFT: blue 1.5pt solid; PADDING-TOP: 0in; BORDER-BOTTOM: medium none"> -----Original Message----- From: <st1:PersonName w:st="on">Stuart Rowley</st1:PersonName> [mailto:Stuart.Rowley@ktd-kyocera.com] Sent: Friday, April 21, 2006 3:33 PM To: McDonald, Ira; wamwagner@comcast.net; Harry Lewis Subject: WIMS Protocol Spec Questions<o:p></o:p> Dear Authors,<o:p></o:p> <o:p> </o:p> I will start with an apology. It must be aggravating to receive this email at the 11th hour, 59th minute. Or actually past that, because these questions should have been made during last call. Therefore, it would be completely understandable for you to just ignore this ill timed email. <o:p></o:p> <o:p> </o:p> All of you have spent zillions of hours working over this spec and on con calls, etc. While I have struggled to find just 5 to 10 hours to thoroughly review the spec. For this I apologize. <o:p></o:p> <o:p> </o:p> I was finally guilted into reviewing the spec, although I have been on crushing internal deadlines, because it just doesn't seem fair for me to not vote or to abstain. I value your efforts on these specs and I want to be informed enough to not give just a rubber stamp vote.<o:p></o:p> <o:p> </o:p> Unfortunately, after my review, I am still not sure I understand it well enough to make a thoroughly informed vote L. Therefore I have included the questions below to help me understand this spec. <o:p></o:p> <o:p> </o:p> If I were to implement this spec, I think I would definitely need an implementers' guide with actual examples.  <o:p></o:p> <o:p> </o:p> Best regards,<o:p></o:p> <o:p> </o:p> Stuart<o:p></o:p> <o:p> </o:p> <st1:PersonName w:st="on">Stuart Rowley</st1:PersonName>, Network Product Mgr.<o:p></o:p> stuart.rowley@ktd-kyocera.com      925 849-3306     925 849-3399 (fax)<o:p></o:p> <o:p> </o:p> Kyocera Technology Development Inc.<o:p></o:p> <st1:Street w:st="on"><st1:address w:st="on">1855 Gateway Blvd. Suite 400</st1:address></st1:Street><o:p></o:p> <st1:place w:st="on"><st1:City w:st="on">Concord</st1:City>, <st1:State w:st="on">CA</st1:State> <st1:PostalCode w:st="on">94520</st1:PostalCode></st1:place><o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> WIMS Protocol Spec Questions<o:p></o:p> <o:p> </o:p> Why is "target" used in the following section? Shouldn't target be "WIMS Managed Entity" instead?<o:p></o:p> 615 GetElements: get value of specified elements from the target at specified time and issue a<o:p></o:p> 616 SendReports<o:p></o:p> 617 SubscribeForAlerts: monitor target for specified alert conditions and issue SendAlerts when they<o:p></o:p> 618 occur<o:p></o:p> 619 UnsubscribeForAlerts: stop specified alert condition monitoring<o:p></o:p> 620 UpdateSchedule: issue a GetSchedule at specified time.<o:p></o:p> 621 Aside from the UpdateSchedule action, by which a WIMS Manager schedules the time at which the<o:p></o:p> 622 WIMS Agent executes a GetSchedule operation, most other actions require the Agent to interact with<o:p></o:p> 623 the target.<o:p></o:p> <o:p> </o:p> <ira> The is editorial legacy - the target object is always a Managed Entity (though not necessarily an entire managed system - the target might be a _job_ or _subunit_).<o:p></o:p> <o:p> </o:p> 645 (3) WIMS Proxy, acting as a WIMS Agent, sends RegisterForManagment request, including supported<o:p></o:p> 646 objects, operations, and actions. Operation arguments include identification of Agent (sender<o:p></o:p> 647 Reference) and Manager (managerURI).<o:p></o:p> Identification of agent? The agent is in the Proxy. Is the device identified? <o:p></o:p> <o:p> </o:p> <ira> Sorry - which 'device' do you mean? The Agent object occurs (usually once) on every managed system - there is a peer System object (MIB-II, HR-MIB, and prtGeneralEntry) that is pointed to by the Agent - the Agent URI includes a hostname.<o:p></o:p> SR> So for a WIMS Agent in a proxy, what does the identification of Agent include?<o:p></o:p> <o:p> </o:p> <o:p><ira-2> For reasons of privacy during fleet management, an Agent (in a Proxy or a leaf-node Managed Entity) need not expose its network URI (hostname or IP address).  This senderReference parameter is of type ObjectAgentReference (defined in 'WimsType.xsd'), which is a sequence of (one or more of) agent integer id (e.g., SNMP Index value), agent name (e.g., Asset Number value), or agent URI.  Bill Wagner championed this requirement for hiding the customer's enterprise network toplogy.</o:p> <o:p></o:p>  663 Figure 4 shows the GetSchedule-Action sequence which will be continually repeated. The WIMS<o:p></o:p> 664 Proxy contacts the Manager to get an updated schedule. In this example the schedule indicates that,<o:p></o:p> 665 at a specific time, the Proxy is to execute a SendReports operation sending the Manager the Printer<o:p></o:p> 666 Marker Life Count data obtained from a specific Managed Entity.<o:p></o:p> How is the specific Managed Entity identified?<o:p></o:p> <o:p> </o:p> <ira> The datastructure 'ActionTargetObjects' (see 'Schedule.xsd') identifies exactly the target Managed Entity. This element is present and REQUIRED in EVERY action definition.<o:p></o:p>  <o:p></o:p> Figure 2<o:p></o:p> RegisterForManagement<o:p></o:p> (senderReference, managerURI,<o:p></o:p> agentPaths,operations,<o:p></o:p> actions, objects )<o:p></o:p> <o:p> </o:p> and associated comment<o:p></o:p> 645 (3) WIMS Proxy, acting as a WIMS Agent, sends RegisterForManagment request, including supported<o:p></o:p> 646 objects, operations, and actions. Operation arguments include identification of Agent (sender<o:p></o:p> 647 Reference) and Manager (managerURI).<o:p></o:p> <o:p> </o:p> Argh, RegisterForManagement is an operation right? Why is it described as a request that can include operations? This makes the example very hard to understand. What operations can a RequestForManagement include?<o:p></o:p> <o:p> </o:p> OK, I get it now. It is supported operations. Maybe I am dense, but this was very hard for me to follow, especially with this text, "Operation arguments include ..." <o:p></o:p> <o:p> </o:p> The following would be more understandable to me:<o:p></o:p> RegisterForManagement<o:p></o:p> (senderReference, managerURI,<o:p></o:p> agentPaths,supported operations,<o:p></o:p> supported actions, supported objects )<o:p></o:p>  <o:p></o:p> <ira> Ok, we could have improved the tags of these parameters, but they're meaning is quite clear in the actual operation signature (from page 42 of the PDF spec):<o:p></o:p> 6.2.1RegisterForManagement<o:p></o:p> RegisterForManagement (senderReference : AgentReference, managerURI :<o:p></o:p> URI agentPaths : AgentPaths,<o:p></o:p> operations :WIMSOperationsSupported,<o:p></o:p> actions : WIMSActionsSupported, objects : WIMSObjectsSupported),<o:p></o:p> statusString : StatusString, operations :<o:p></o:p> WIMSOperationsSupported,<o:p></o:p> actions : WIMSActionsSupported, objects : WIMSObjectsSupported, <o:p></o:p> schedule : Schedule<o:p></o:p>  <o:p></o:p> 645 (3) WIMS Proxy, acting as a WIMS Agent, sends RegisterForManagment operation, including supported<o:p></o:p> 646 objects, operations, and actions. RegisterForManagment arguments include identification of Agent (sender<o:p></o:p> 647 Reference) and Manager (managerURI).<o:p></o:p> But aren't supported operations, actions, and objects also arguments of RegisterForManagement?<o:p></o:p> <o:p> </o:p> <ira> They _are_ inputarguments - see the operation signature above. <o:p></o:p> SR> If they are all input arguments, then listing them separately in the two sentences in 645 - 647 with only identification of Agent and Manager identified as arguments is confusing.   <o:p></o:p> <o:p></o:p> <ira-2> Agreed - arguments should be clearly labelled as input or output.  And actually, the term parameters is universally used in the schema for arguments (the construction 'output parameter' makes more sense).    ManagerAgentSupported<o:p></o:p> I am having a tough time understanding Figure 6. This is to get the list of actual devices that are "fronted" by the proxy, right? I can find no explanation of ManagerAgentSupported.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <ira> Nope - you have to read'WimsBase.xsd' - all of the details of the WIMS multifunction objects that will be added to the SM/2.0 release are defined ONLY in the schema - we rejected writing an awful IPP-style thousand-page spec.<o:p></o:p>  <o:p></o:p> In Figure 7, I just don't get this. I can find no description of the AgentInfo element. What is a (mapped) Agent object? Shouldn't "reads" be "requests"?<o:p></o:p> 770 (3) WIMS Manager reads description of legacy agent by sending ExecuteAction request containing<o:p></o:p> 771 GetElements action for AgentInfo element in (mapped) Agent object.<o:p></o:p>  <o:p></o:p> <ira> See above - read 'WimsBase.xsd' - AgentInfo is the description of the Agent, consistent with 'printer-info' attribute of an IPP Printer object. We used the verb 'reads' here because these are examples - NOT the normative definitions of operations and objects.<o:p></o:p> <o:p> </o:p> 784 may be used. Because a WIMS Proxy must contain a WIMS Agent, and may contain a WIMS<o:p></o:p> 785 Manager,<o:p></o:p> I think this sentence does not match the Imaging System Model (Figure 1). The Proxy in Figure 1 includes a Manager. This Manager is shown talking to both a WIMS Agent and a Legacy Agent. If it is talking to a WIMS Agent doesn't it need to be a WIMS Manager? If it is talking to a Legacy Agent, I guess it would not be a WIMS Manager. I think this section about chained Proxies requires that the Proxy in Figure 1 be modified to include both a WIMS Manager (connecting to the downstream WIMS agent) and a non-WIMS Manager (connecting to the downstream Legacy agent).<o:p></o:p> <o:p> </o:p> <ira> Bad terminology.  There is no such thing as a first-class WIMS Proxy object.  A WIMS Manager control ONLY a downstream WIMS Agent (using WIMS protocol).  A WIMS Agent in a _proxy_ system talks to its upstream (parent) WIMS Manager and forwards operations to one or more downstream WIMS Managers and/or Legacy Managers.  Bill would say that an intermediate layer WIMS Manager could also speak SNMP to target devices - this is modelling purity issue.<o:p></o:p> SR> Are you agreeing with my point?<o:p></o:p> <o:p> </o:p> <o:p> <ira-2> YES - I'm agreeing with your point that the terminology here needs cleanup - for clarity, we should describe a WIMS Agent (in a WIMS Proxy system) as forwarding operations to WIMS Managers (for downstream WIMS protocol) and Legacy Managers (for SNMP, IPP, etc.).  BUT - the abstract object Manager models a unified WIMS Manager and Legacy Manager and can represent adjacent upstream Agents (ManagerParentAgentSupported list), adjacent downstream Agents (ManagerAgentSupported list) and multi-hop paths to Managed Entities (ManagerAgentPathSupported list).</o:p>  <o:p></o:p> 790 Proxies. Implementations are free to decompose the schedule received by an agent and use the<o:p></o:p> 791 recovered Action information to create a new schedule to be passed on.<o:p></o:p> What does "recovered Action information" mean? <o:p></o:p> <o:p> </o:p> <o:p> </o:p> Figure 9:<o:p></o:p> I understand from the text that agentPath (shouldn't it be agentPaths as listed in 6.1.1?) expands to include all agents in the entire chain. What exactly does this look like? Does the ManagerURI also expand in this same way? If this example included sample ManagerURI and agentPath strings, I think it would be substantially more understandable to me.<o:p></o:p> <o:p> </o:p> <ira> Yes, it _is_ AgentPaths in all the Action definitions in Schedule.xsd.  We added these extensive examples after last call comments - but the examples lay the reader open to various misunderstandings - the whole chapter should begin "The following examples are informative - anywhere they disagree with the normative Operation and Action definitions, the normative definitions take precedence."<o:p></o:p>  <o:p></o:p> 866 � In the WIMS Agent Interface, the WIMS Agent always initiates the connection and sends<o:p></o:p> 867 operation requests to the superior WIMS Manager.<o:p></o:p> What about the communication between a WIMS Agent and a WIMS Manager within a proxy?<o:p></o:p> <o:p> </o:p> <ira> Internal implementation detail - I wrote a proposal a year agoto define the operation forwarding API between a WIMS Agent and its co-located WIMS Manager in a proxy system, but there was strong pushback to abandon it. <o:p></o:p> SR> This text just seems like it needs a qualifier because a WIMS Agent in a proxy also communicates by some out of band method to the proxy WIMS Manager.<o:p></o:p> <o:p></o:p>  <o:p><ira-2>  So, perhaps we should append to the end of the sentence above "...superior WIMS Manager and forwards operation requests to co-located subordinate WIMS Managers and Legacy Managers (by an implementation-defined method)."</o:p> <o:p></o:p><o:p></o:p>  870 5.2 Associated Port<o:p></o:p> Unless port 80 is explicitly specified then port 4951 will be assumed and firewalls will block WIMS unless holes for 4951 are made. Do we really expect anyone will implement WIMS using 4951? <o:p></o:p> <o:p> </o:p> <ira> Works fine - HTTP Clients within the enterprise (to whit, WIMS Agents) open _outbound_ HTTP connections to port 4951 on the WIMS Manager at the fleet management vendor - firewalls will allow that (non-system) port outgoing by default - this is no different from IPP/1.1 requiring default operation over port 631 and disallowing operation over port 80 unless explicitly enabled by the system administrator - follows a rather firm IETF policy directive on the reuse of port 80 by non-web-browsers.<o:p></o:p> SR> I am aware of the IETF policies. I believe that the default operation of all firewalls is to allow outbound connections on port 80 and to block outbound connections on ports 631 or 4951 (that is how my corporate firewall is configured). The theory is great, but in practice we know that getting organizations to punch holes in firewalls is much more difficult than having a non-conforming default implementation that uses port 80. This is of course why port 80 is so over used. Unless firewall vendors can be convinced to open port 4951 outbound as part of a default configuration, I would bet that every vendor implementing WIMS will default to port 80. However, I am not suggesting any changes to the spec :-)<o:p></o:p> <o:p>  </o:p> <o:p> <ira-2> Strong disagreement - every vendor had better default to 4951 and _allow_ the administrator during installation to enable 80 (just like conforming IPP/1.1 implementations) - otherwise they are non-conforming and people like US NIST and various government agencies are going to notice and NOT buy those products.  Also,</o:p> <o:p>there is a profound difference between 631 (a kernel-only system port) and 4951 (an IANA-registered application port).  Good quality firewalls allow outbound connections to non-privileged application ports by default (although they may examine the content) - that's how CUPS works out-of-the-box with port 8631 for an End User.</o:p> <o:p> </o:p> 891 A WIMS URI MUST be represented in absolute form,<o:p></o:p> 910 If the 'path-absolute' element is not present in a WIMS URI,<o:p></o:p> These are not in conflict?<o:p></o:p> <o:p> </o:p> <ira> No - 'path-absolute' is AFTER the hostname - read RFC 3986 (replaces 2396), which changed the names ofmany of these ABNF productions.<o:p></o:p> <o:p> </o:p> Figure 10.<o:p></o:p> What is the intention of the double pointed arrow between the proxy and the other entity on the same side of the firewall? I think this would be interesting to include in this diagram. Does the Proxy implement separate WIMS Agent and WIMS Manager interfaces to communicate to downstream WIMS agents and managers?<o:p></o:p> <o:p> </o:p> <ira> Argh!  We shouldn't have included all these diagrams!  That double-headed arrow is actually a WIMS or Legacy Manager (in the proxy) talking to a WIMS or Legacy Agent (in the bottom managed entity).<o:p></o:p> <o:p> </o:p> 1002 Each "interface" consists of a set of "Operations" that the Agent or Manager can initiate. Some of the<o:p></o:p> 1003 operations invoke "Actions" by the Agent. The operations and actions in the following paragraphs are<o:p></o:p> 1004 defined in the form:<o:p></o:p> 1005 OperationName (OperationParameters) Responses, and<o:p></o:p> 1006<o:p></o:p> 1007 ActionName (ActionParameters)<o:p></o:p> I am having amazing trouble understanding the relationship between Operations and Actions. These two lines (1005 and 1007) confuse me completely. See the following text snippets.<o:p></o:p> <o:p> </o:p> 650 PWG standard status of "SuccessfulOk", and an initial Schedule. In this example, the only Action in<o:p></o:p> 651 the Schedule is a later GetSchedule operation.<o:p></o:p> <o:p> </o:p> 657 scheduled actions usually is that the WIMS Proxy contacts the WIMS Manager with a GetSchedule<o:p></o:p> 658 request.<o:p></o:p> <o:p> </o:p> In this example, the WIMS Manager needs to work with the information 660 provided in<o:p></o:p> 661 RegisterForManagment to develop a plan for managing the Object (the ManagedEntity). The initial<o:p></o:p> 662 schedule therefore includes only a scheduled GetSchedule action.<o:p></o:p> 663 Figure 4 shows the GetSchedule-Action sequence which will be continually repeated. The WIMS<o:p></o:p> <o:p> </o:p> In these sections, GetSchedule is described as an action, a request, an operation, and an operation included in an action. Wow. I think it is critical to understand the relationship between actions and operations, and frankly I am having a tough time with it.<o:p></o:p> <o:p> </o:p> <ira> These are remaining typos (to be FIXED, Bill) in the spec - the name of the Action is UpdateSchedule (see Schedule.xsd), whichcauses a mandatory GetSchedule operation (in a timely manner after the UpdateSchedule action triggers).<o:p></o:p> <o:p> </o:p> <o:p> </o:p> 1032 objects : WIMSObjectsSupported<o:p></o:p> 1033 List of objects supported by this WIMS Agent in the case of Agent Operations, and by this WIMS<o:p></o:p> 1034 Manager in the case of Manager Operations.<o:p></o:p> There is no example that I can find that shows what it would actually look like. I am guessing the text in the actual operation would be something like: objects : WIMS_object1, WIMS_object2, WIMS_object3; <o:p></o:p> Shouldn't it describe this? I assume it is described by reference to some accepted format, but it is not obvious to me.<o:p></o:p> <o:p> </o:p> <ira> No -all encoding details will be specified in the future, separate WIMS Transport Bindings spec (just like IPP/1.1 RFC 2910), which is early work-in-progress.  After Jerry asked for specific SOAP examples during the last call, we renamed this spec to "WIMS Abstract Protocol" and removed transport binding details. <o:p></o:p> <o:p> </o:p> 1142 1. Managed Entities to be identified as being manageable by the specified WIMS Manager through<o:p></o:p> 1143 a WIMS Agent or Legacy Agent,<o:p></o:p> I don't think Legacy Agent makes sense here. How can a Legacy Agent be managed by a WIMS Manager?<o:p></o:p> <o:p> </o:p> <Ira> Nope - makes sense here -some AgentPaths can terminate in a Legacy Agent URI (e.g., 'snmp://example.com:161').<o:p></o:p> <o:p> </o:p> <o:p> </o:p>  <o:p></o:p></BLOCKQUOTE></DIV> -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 4/21/2006 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 4/21/2006 </BLOCKQUOTE> -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 4/21/2006 -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.5/321 - Release Date: 4/21/2006 </BLOCKQUOTE></BODY></HTML> -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.6/323 - Release Date: 4/24/2006