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

[peter van der Stok <[e-mail]>]

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

Kovatsch, Matthias schreef op 2018-04-25 23:29:
> 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