[core] Definition of the ins target attribute - WAS: Endpoint Client Name / Endpoint Name in RD draft

peter van der Stok

2018-04-26 09:14:16 UTC

Hi Matthias,

On of the confusing aspects is indeed the domain.
Domain is used in two senses:
+ d= as a local domain definition within rd to group resources
+ domain as used in DNS

In earlier RD texts a mapping was suggested between d= and the DNS
domain.
That was abandoned because unusable for most building installations as
we know them.

The mapping may be possible for other installations, but it certainly
cannot be a general rule.

The RD-DNS-Sd draft does not want to suggest that you need to learn
DNS-SD to do core discovery,
but you have to learn DNS-sd to get the RD to DNSSD mapping right.
ins is an important attribute to select the service type instance needed
for dnssd.

I am happy to learn how you want to fit ins values into RD discovery.
Possibly you need a new attribute in RD
given that the mapping from RD to DNSSD is not always 1-1.

Greetings,

Peter

Post by Kovatsch, Matthias
Dear all
My motivation for raising this issue was that I learned that "ins" is
used differently from its (original) purpose. I agree that there is no
special handling of "ins" by RD. Having it in the DNS-SD draft might
shift its meaning or at least perception and definitely visibility.
Writing its own draft for just "ins" is overkill, though.
"ins" has an important role within CoRE discovery and we should avoid
that people overlook it, because they think they do not need DNS-SD
(and they do not need it for CoRE discovery). So we need to nail down
its definition and probably mention it in multiple drafts (with proper
references). I read the text in core-rd-dns-sd and it is roughly fine,
but sounds a bit like I have to learn DNS-SD to do CoRE discovery.
Also I am not sure about the following statements within the same

"SHOULD be unique across resources with the same Resource Type
attribute in the domain it is used."

Is "domain" corresponding to RD's "d" parameter and attribute?

"This attribute is used by a Resource Directory to distinguish between
multiple instances of the same resource type within the directory"

Here it sounds like it needs to be unique across all resources with
the same Resource Type attribute in the RD.
Logically and historically, I would have expected that "ins" MUST be
unique across all resources with the same Resource Type attribute in
one device (=ep). I don't know if there is a conflict with DNS-SD
here, so that we cannot define this. Yet a definition to be unique
When unique within "ep", a device from the factory could already have
"ins" attributes for its resources, for instance, a weather station
with two temperature sensors, one ins=indoor, one ins=outdoor.
When unique within "d", someone had to rewrite the "ins" attributes,
so that they match the deployment or application, for instance,
ins="indoor kitchen", ins="indoor lobby", ins="outdoor terrace",
ins="outdoor garage".
Do we actually have rough consensus on what "ins" actually means and
how it should be used for discovery within CoRE?
(There is a high chance that I just missed that due to being busy with other stuff...)
Best wishes,
Matthias

-----Ursprüngliche Nachricht-----
Gesendet: Dienstag, 24. April 2018 11:40
An: Jim Schaad
Cc: Kovatsch, Matthias (CT RDA IOT EWT-DE); 'Christian Amsüss';
Betreff: Re: [core] Endpoint Client Name / Endpoint Name in RD draft

Related to this is the proper definition of "ins", which
unfortunately was moved over to the core-rd-dns-sd draft. "ins" is
used to distinguish resources with the same "rt". Originally, it was
used for resource within the same device (e.g.,
</t1>;rt=temperature;ins=indoor,</t2>;rt=temperature;ins=outdoor). By
now, it often is assumed to require global uniqueness. I claim that
this is not required when "ep" is used correctly. Using a hierarchy
of "d" -> "ep"
-> "ins"
provides more flexibility than making "ins" globally unique. "ins"
can still have a global meaning (cf. indoor vs outdoor), but it
should be re-usable for all resources with similar instance
semantics. Uniqueness is achieved through "d" and "ep".
I think "ins" should become part of the RD draft again to be defined
together with "d" and "ep", as they are part of a larger discovery
framework.

If "ins" does not need to be handled in a special manner by the RD,
then I would see no reason for it to be part of the RD draft. Both
"ep" and "d" are treated in a special manner as the pair is required
to be globally unique in the RD. This is not a true statement for the
"ins" attribute even in the core-rd-dns-sd draft.
Jim

"Ins" is used to specify the instance name for DNS records necessary
for DNS-sd service specification the RD-DNS-SD draft specifies
the rules to generate ins values As such it is totally proper that
"ins" rules are specified in a separate draft, because "ins" treatment
is
disconnected from the special treatment specified for "ep" and "d".
Matthias, Are you expressing that an additional need exists to distinguish registrations?
Peter