Subject: [core] CoRE RD update registration: replace links or update and add to existing links?

From: Michael Koster <[email-masked]>
Date: Mon, 14 Jul 2014 09:13:46 -0700

See the CoRE RD draft:
http://tools.ietf.org/html/draft-ietf-core-resource-directory-01

Sec. 5.3:
Parameters that have not changed SHOULD NOT be included in an update.

I take this to mean that, if I include link-format data in the payload of an RD update request, the links will be used to replace existing links that match the <URL> part, and add new links to the existing registration. IOW, I expect to be able to add and update links without re-registering links that I’m not updating.

Does anyone have a different interpretation of this? 

I would like to add text to the next update (overdue BTW) of the document to make the update link behavior explicit as a point of interoperability.

Cheers,

Michael

---

From: Zach Shelby <[email-masked]>
Date: Mon, 14 Jul 2014 21:05:04 -0700

Hi,

Actually, the update mechanism does not even include a payload, and thus links can not be updated with this mechanism. Instead, if your links change, you need to register again. The reason for this, is that registration update processing needs to be very efficient considering they are performed much more often than registration.

Painfully aware I missed the update deadline for Toronto, and will submit when that opens up on site.

Zach

On Jul 14, 2014, at 9:13 AM, Michael Koster <[email-masked]> wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

Zach Shelby
Director of Technical Marketing
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

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

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Jul 2014 07:26:28 +0200

On 15 Jul 2014, at 06:05, Zach Shelby <[email-masked]> wrote:

> the update mechanism does not even include a payload

Maybe “refresh” would be a less confusing name for this function.

Grüße, Carsten

---

From: Michael Koster <[email-masked]>
Date: Tue, 15 Jul 2014 10:41:51 -0700

The use case I have in mind is adding additional descriptive links to existing resources after an endpoint registers, which would be based on context and other late binding factors. Also it will be useful to dynamically add objects and resources, which would require registering more links to an EP. It’s not as important to change existing links.

Reg update could include a payload only when links are to be added, and be empty when only refreshing, or a POST to the location might be defined to add more links to an EP, but maybe registration update isn’t the best place to think about adding or updating links.

For adding links to point to an EP, could we register another EP and set the context to the already-registered EP? That way, there would be separate management locations but the links would all point to the same EP. 

For changing links or relation values, it would be unregister and re-register the EP with the new links. 

Does this make sense?

Thanks,

Michael

---

From: Michael Koster <[email-masked]>
Date: Sat, 19 Jul 2014 15:51:31 -0700

Hi Zach,

Thanks for the reply. I appreciate the need to make updates efficient, but maybe some less frequent updates can carry payloads.

The update description in the current RD draft doesn't say anything at all about the payload, which may have left an opening for the definition in LWM2M implying a payload of “objects and object instances”. I may be misunderstanding the following table in the OMA LWM2M specification section 5.2.2 (Update) which implies that objects and object instances can be updated:

Parameter

Required

Lifetime

No

Binding Mode

No

SMS Number

No

Objects and Object Instances

No

This plus the text 
"This “Update” operation MUST contain only the parameters listed in Table 5 which have changed compared to the last registration parameters sent to the LWM2M Server.”

strongly implies that new objects  and instances can be registered as part of the update registration operation. This could be specific to LWM2M implementations of RD, but I believe it may be a useful extension.

ref: http://openmobilealliance.hs-sites.com/lightweight-m2m-specification-from-oma