[ws-dd] Issue 133: Metadataversion in metadata

["Ingo Lueck" <ingo.lueck@udo.edu>]

------------------------ Urspr�ngliche Nachricht -------------------------
Betreff: RE: [ws-dd] Issue 133: Metadataversion in metadata
Von:     "Dan Driscoll" <Dan.Driscoll@microsoft.com>
Datum:   Di, 13.01.2009, 16:52
An:      "ingo.lueck@udo.edu" <ingo.lueck@udo.edu>
--------------------------------------------------------------------------

Hi Ingo-
Thanks for putting together this proposal.  Please forward it to the WS-DD
TC mailing list--during the last conference call (or the call before
that?) the objections to this issue came from other TC members.

Thanks very much
--D

-----Original Message-----
From: Ingo Lueck [mailto:ingo.lueck@udo.edu]
Sent: Tuesday, January 13, 2009 7:46 AM
To: Dan Driscoll
Subject: RE: [ws-dd] Issue 133: Metadataversion in metadata

Hi Dan,

my proposal is to add the metadata version as an element to ThisDevice.
I think this is quit a small change to provide a reliable way of getting
the correct metadata version:


SCHEMA:
  <xs:element name="ThisDevice" type="tns:ThisDeviceType" />
  <xs:complexType name="ThisDeviceType" >
    <xs:sequence>
      <xs:element name="FriendlyName" type="tns:LocalizedStringType"
          maxOccurs="unbounded" />
      <xs:element name="FirmwareVersion" type="xs:string"
          minOccurs="0" />
      <xs:element name="SerialNumber" type="xs:string" minOccurs="0" />
      <xs:element ref="wsd:MetadataVersion" />
      <xs:any namespace="##other" processContents="lax"
          minOccurs="0" maxOccurs="unbounded" />
    </xs:sequence>
    <xs:anyAttribute namespace="##other" processContents="lax" />
  </xs:complexType>


EXAMPLE:
<wsdp:ThisDevice
      xmlns:wsdp="http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01"; >
    <wsdp:FriendlyName xml:lang="en-GB" >
      ACME ColourBeam Printer
    </wsdp:FriendlyName>
    <wsdp:FriendlyName xml:lang="en-US" >
      ACME ColorBeam Printer
    </wsdp:FriendlyName>
    <wsd:MetadataVersion>75965</wsd:MetadataVersion>
</wsdp:ThisDevice>


Best regards,
    Ingo




> Hi Ingo-
> In both cases, the only consequence of having an out-of-date metadata
> version is that the client may have to retrieve metadata one extra time if
> an updated Hello is published with the existing metadata version.
>
> This seems like an optimization problem that will not be a problem in
> usual operating environments.
>
> Do you have a concrete proposal to bring to the TC?  If we do not have a
> concrete proposal, we cannot make any changes to the specification.
>
> The concerns raised on the last call indicate to me that this will be
> difficult to solve, and that it only helps optimize the message exchange
> (i.e., it is only to support optimizing the case where a message is lost,
> or to support other optimizations such as out-of-band address
> configuration).
>
> Thanks
> --D
>
> -----Original Message-----
> From: Ingo Lueck [mailto:ingo.lueck@udo.edu]
> Sent: Monday, January 12, 2009 11:01 AM
> To: Dan Driscoll
> Subject: Re: [ws-dd] Issue 133: Metadataversion in metadata
>
> Hi Dan,
>
> here are two patterns for this issue:
>
> Pattern one:
>
> * Device issues Hello with metadataversion=1; client receives Hello;
> * Device issues Hello with metadataversion=2; Hello dropped due to network
> congestion
> * Client needs the Device now and retrieves metadata;
>
> Now the client has metadata of version 2 but assumes that it is version 1.
>
>
> Pattern two:
>
> * Device is already running
> * Client comes to the network and knows the Address of the Device already
> (by configuration, persistence or any other way)
> * Client retrieves metadata
>
> Now the client has metadata but does not know the associated version
> number. It could get the version number by means of a Probe or Resolve
> request but this generates much traffic and delay just to figure out the
> version number. Moreover, even doing so the client can't be sure to know
> the correct number in the end. Here is the extended pattern:
>
> * Device is already running (metadataversion=1)
> * Client comes to the network and knows the Address of the Device already
> (by configuration, persistence or any other way)
> * Client retrieves metadata
> * Device issues Hello with metadataversion=2; Hello dropped due to network
> congestion
> * Client sends a probe directly to the Device; client receives Probe Match
> with metadataversion=2
>
> Now the client has metadata of version 1 but assumes that it is version 2.
>
>
> I think adding the metadata version number to the metadata is a small and
> straightforward change that solves all these Problems.
>
> Best regards,
>     Ingo
>
>
>
>> Hi Ingo-
>> I would like us to make progress on this issue before the conference
>> call
>> next Tuesday.  I believe some other members of the TC raised concerns
>> about this proposal in December.
>>
>> I was thinking about this issue-does this problem actually exist?  I'm
>> trying to follow the pattern where a client could associate the metadata
>> with an old version.
>>
>> I believe the pattern goes like this:
>>
>>
>> *         Device issues Hello with metadataversion=1; client receives
>> Hello; client retrieves metadata
>>
>> *         Device issues Hello with metadataversion=2; Hello dropped due
>> to
>> network congestion
>>
>> *         Device issues Hello with metadataversion=3; client receives
>> Hello; client retrieves metadata
>>
>> At both points (metadataversion=1, metadataversion=3), the client simply
>> retrieves the metadata and knows that it is the latest version.  Even if
>> the device does not revise its metadataversion after the dropped Hello,
>> the client will always receive the metadataversion in the most recent
>> WS-Discovery message.
>>
>> Can you describe the case where metadataversion inside metadata is
>> required?
>>
>> Thanks!
>> --D
>>
>
>
>
>