Re: [core] Endpoint Client Name / Endpoint Name in RD draft

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

>> 
>> 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