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

["Kovatsch, Matthias" <[e-mail]>]

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 section 2.1:

> "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 within "d" seems to aim for application semantics:

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-----
> Von: peter van der Stok [mailto:[e-mail]]
> Gesendet: Dienstag, 24. April 2018 11:40
> An: Jim Schaad
> Cc: Kovatsch, Matthias (CT RDA IOT EWT-DE); 'Christian Amsüss'; [e-mail]; [e-mail]
> 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