RE: Topic 5: targeting Based on UID

[Ian B]

I agree and don't plan to support it if it happened.

There is also the code needed to setup these device ID's assuming the
embedded device does not ship with them pre-programmed.

Ian

>-----Original Message-----
>From: Kevin Hawkins [mailto:<a
href="/group/xAP_developer/post?postID=jSZhmFPZKEj0aLvHPAxl2jRZlMjv_4gsMlKWr-29JjhDteMTrMCGl1uo5wUAI8fs1SheEECNmDL41NAVNvvpGUg">lists@u...</a>]
>Sent: 10 June 2003 18:35
>To: <a
href="/group/xAP_developer/post?postID=P0RcEuVVfQ-zBh_QCedFatmgx3nOqFfyHbC2Zh-qRQ7mCX6Uk5wjCy0hB4Y8YadAhlXc4Cjv-UQlDDifu9jKok4efKc">xAP_developer@xxxxxxx</a>
>Subject: [xAP_developer] Topic 5: targetting Based on UID
>
>
>
>Initially I was very pro adding this feature but in thinking through it
I
>have done an about turn - I am raising the topic to see if there
>is an angle
>I have missed.
>
>Currently - it is not possible to target a device based on its UID eg
>
>TargetUID="FF123400"
>
> Let me explain why this was not permitted in v1.2. xAP is
>essentially a broadcast protocol and interested parties can
>eavesdrop on any
>conversation that they want. As long as we stay with UDP, using the
same
>port and the broadcast address (and a defined packet format) then this
will
>remain true. It cannot be circumvented without changing one or other of
>these.
> Currently a device when sending a xAP message must include its UID
>and its (longform) source address in all its transmissions. This is so
that
>listeners wanting to monitor the information based on source
>address or more
>importantly a wildcarded source address can do so. Eg
>source="UKUSA.TempSensor.>" to monitor all the temperature
sensors from
>UKUSA. It is critical to wildcarding operation that the full source
address
>is present.
> Now suppose that we allowed targeting based on UID. TargetUID =
>FF123400. The targets longform address is not being sent so another xAP
>sitting on the network and monitoring all messages based on
>Target=UKUSA.TempSensor.* would not see such a message. Such a xAP
device
>might for example be monitoring temperature sensors to see if any
setpoints
>were changed in a building. Can we get around this ? Well yes we would
have
>to mandate that whenever a target=UID was sent the longform
>address was also
>included - this is only the same thing as saying that when we send UID=
we
>must also send our source address in full.
> So what would be the benefit of allowing TargetUID= in a header ? I
>originally had two areas of interest in this.
> My first was as a solution to storage restrictions in small PIC
>devices. The UID is currently invaluable in that a xAP receiver can
simply
>link itself to a transmitter by storing the UID (rather than the source
>address) of the transmitter in memory - so instead of having to filter
>"UKUSA.FourGangSwitch.Downstairs.Lounge:Switch1" it can store
FF121201 and
>all is well - 4 bytes - a saving of 90% over the full string - a huge
>advantage of xAP over say xPL as well - great for low spec devices. So
what
>about the converse ? How about a low power switch being able to just
target
>a lamp based on UID - now again the low power switch can make the same
>savings - but actually it can't because it would have to send the full
>target address as well. Are there ways around this ?? Well yes,
>but they are
>not tidy. You could enlist a 'helper' (cache) on a xAP network that
>monitored any devices targeting just based on UID and filled in the
targets
>full address as well, or you could just allow it as a device
>restriction. My
>feelings now are that the latter is unacceptable and the former
>overcomplicates the whole operation of xAP. Is there any other way
around
>this anyone can think of ?? Bear in mind that a PIC controller might
>typically only have 10's of bytes of RAM although these addresses could
be
>held in external EEPROM as well.
> Secondly - configuration - being able to target a device that has no
>source name set up yet. Again I thought this would be a fantastic
advantage
>of TargetUId= but in reality you can just use the UID as a temporary
full
>source address anyway as it should be unique Target=FF123400 or if xAPs
are
>picky on their source address parsing then perhaps Target=FF.1234:00.
Of
>course the UID has to be unique in the first place but that's a
>configuration issue. So again no benefit...
> Whilst on this UID usage point can I stress that the xAP spec
>reserves 00 and FF in all cases in the UID component places as
'reserved ie
>xx0000xx, xxxxxxFF and 00xxxxxx etc are reserved. Local network ID's
should
>be FF (one of the reserved cases) and devices with no hardware subs
should
>end in 00. I am expecting that we may use xxFFFFxx as a way of
introducing
>virgin xAP devices onto a network and auto configuring them, but that's
>another topic.
> So anyone got a case for Targeting based on UID or shall we close
>this one ?
>
> Kevin
>
>
>
>To unsubscribe from this group, send an email to:
><a
href="/group/xAP_developer/post?postID=fNbtirVlCZbQ5A2_6HeX9hrUSAJw4EnZ16reP12DXsz8qNXToEeyOWAERDkwx5mb_A3sRl3YeI_38YAnWQf6pGb99_pwh9iLjRN5PnL5VfJa">xAP_developer-unsubscribe@xxxxxxx</a>
>
>
>
>Your use of Yahoo! Groups is subject to <a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a>
>
>
>