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

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

Hi Hannes,

I share your concerns, But there are some additional aspects.
for 3rd party registration the con= is used.
con= will also be used to indicate alternative transports. Suppressing 
con= seems really a waste in this stage.
On the other hand, even suppressing con= for third parties, the anchor 
attribute also permits to refer to third parties. Removing the anchor 
attribute is cumbersome to say the least.

Possibly @others want to react.

For the moment using con= for 3rd party registration creates one 
registration at the time.
The Authorization server can also in this case assign endpoint values 
and prevent ep value stealing.

I will try to get some concrete feedback on 3rd party registration. I 
will keep you informed.

Peter

Hannes Tschofenig schreef op 2018-05-08 13:20:
> Peter,
> 
> I would personally feel more comfortable if we standardize
> functionality that some people have gained some experience already. If
> we don't involve the domain experts then we will most likely get it
> wrong.
> 
> What about separating this functionality from the RD draft, reach out
> to these companies, and then put the result of the investigations into
> a separate document? There are some folks in the group who work
> closely with indoor commercial lighting companies and they could for
> sure help.
> 
> Ciao
> Hannes
> 
> 
> -----Original Message-----
> From: peter van der Stok [mailto:[e-mail]]
> Sent: 08 May 2018 08:22
> To: Kovatsch, Matthias
> Cc: Hannes Tschofenig; Mohit Sethi; [e-mail]
> Subject: Re: [core] Conclusion -- Endpoint Client Name / Endpoint Name
> in RD draft
> 
> Kovatsch, Matthias schreef op 2018-05-07 18:09:
>> Dear Hannes,
>> 
>> dear list
>> 
>> To my knowledge, third-party provisioning functionality is in
>> particular used for lighting systems; maybe Peter can comment on this.
> 
> On request, some background.
> For buildings, the installation is done by installation companies with
> their own tools and procedures.
> Installation can be done in phases by different companies.
> Their is at this moment not one general approach or installation 
> protocol.
> 
> The problem is that the architect and people around have produced
> drawings with cabling and equipment situated at precise physical
> locations in the drawing.
> Equipment, cabling etc are identified with numbers ,names, what have 
> you.
> There are descriptions which discuss the functionality and the
> relation between the equipment.
> All this knowledge has to be transferred to the equipment without
> making too many "one of a kind" pieces.
> In he "olde times" much was solved by the cabling, that limited the
> control possibilities.
> These IP times, anything can reach anything else.
> One approach is to store parts of this information into the RD, which
> can be queried by the equipment.
> 
> I hope this make the wish for an RD with third party access 
> understandable.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.