Subject: Re: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-00.txt

From: Antonio Jara <[email-masked]>
Date: Wed, 4 Jan 2012 15:22:26 +0100

Hi Zach,

Regarding the integration of sensors/actuator from legacy technologies and
protocols which are being adapted to 6LoWPAN/IPv6. For example, in building
automation a EIB/KNX device or X10 device, which is integrated in a gateway
to be enabled/powered with CoAP and IPv6 access.

The description of this interfaces in the gateway for the DNS-SD could be
core#x10_s or something like that. Or this specification of the technology
is more focused on the "resource type" parameter that in the "interface"
one.

Best regards, thanks so much, and happy 2012!,
Antonio Jara

On Mon, Jan 2, 2012 at 5:41 PM, <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/core
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send core mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/core
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of core digest..."
>
> Today's Topics:
>
>   1. Re: [hiprg] Research topics discussion - meeting suggestion:
>      Wednesday 7:30pm (Miika Komu)
>   2. Fwd: New Version Notification for
>      draft-shelby-core-interfaces-00.txt (Zach Shelby)
>   3.  #180: Update ABNF for queries (core issue tracker)
>   4. Re: #178: Multiple relation types (core issue tracker)
>   5. Re: #178: Multiple relation types (core issue tracker)
>   6. Re: #179: SHOULD NOT for multicast response repression
>      (core issue tracker)
>   7. Re: #180: Update ABNF for queries (core issue tracker)
>
>
> ---------- Forwarded message ----------
> From: Miika Komu <[email-masked]>
> To: "René Hummen" <[email-masked]>
> Cc: [email-masked], core <[email-masked]>
> Date: Mon, 02 Jan 2012 07:46:13 +0200
> Subject: Re: [core] [hiprg] Research topics discussion - meeting
> suggestion: Wednesday 7:30pm
> Hi,
>
> I sent privately a number of references for Struik but here's the most
> essential ones. Regarding to ease-of-use considerations, and UIA [1]
> extends HIP-like security to user-level identities. We have also conducted
> some usability tests with a HIP GUI [2] earlier.
>
> Regarding to security, references [3,4] are worth checking out because
> they have helped to improve the security in HIP.
>
> [1] http://www.pdos.lcs.mit.edu/**papers/uia:osdi06.pdf<http://www.pdos.lcs.mit.edu/papers/uia:osdi06.pdf>
>
> [2] Kristiina Karvonen, Miika Komu and Andrei Gurtov, Usable Security
> Management with Host Identity Protocol, published in The 7th ACS/IEEE
> International Conference on Computer Systems and Applications (AICCSA-2009)
>
> [3] Krawczyk, H. and P. Eronen, "HMAC-based
> Extract-and-Expand Key Derivation
> Function (HKDF)", RFC 5869, May 2010.
>
> [4] Aura, T., Nagarajan, A., and A. Gurtov,
> "Analysis of the HIP Base Exchange
> Protocol", in Proceedings of 10th
> Australasian Conference on Information
> Security and Privacy, July 2003.
>
> On 31/12/11 19:04, René Hummen wrote:
>
>> Hello René,
>>
>> this email contains a few references to papers regarding the security
>> properties and embedding of HIP in today's network environments.
>>
>> First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To be
>> exact, it is a derivate of the basic protocol described in Section 5.1, as
>> the HIP BEX is triggered by a separate (empty) message that is not included
>> in the SIGMA protocol family. This allows HIP to perform DoS protection
>> against exhaustive public key-based operations by the responder by means of
>> cryptographic puzzles. Furthermore, the public key (A) of the responder is
>> already sent in the first response message. However, this does not impact
>> the security properties, but rather the anonymity of the responder.
>>
>> Regarding the usage of HIP, there is a rather comprehensive journal
>> article [2] that describes the architecture as well as the operation system
>> and infrastructure requirements of HIP. It also provides some pointers to
>> further papers that may be worth reading for you. Additionally, Samu
>> Varjonen recently published a paper on the "Secure Resolution of End-Host
>> Identifiers for Mobile Clients" [3]. However, it seems to be inaccessible
>> at the moment. Still, you may want to refer to it at later point in time,
>> as it describes an approach to resolve HITs to IP addresses.
>>
>> I hope that this small selection is helping you in understanding the
>> properties of HIP. I would also like to invite other people to contribute
>> to this discussion, e.g., by providing further references relevant for the
>> CoRE WG.
>>
>> Regards,
>> René
>>
>>
>> [1] Krawczyk, H.; SIGMA: The ‘SIGn-and-MAc’ Approach to Authenticated
>> Diffie-Hellman and Its Use in the IKE Protocols, ADVANCES IN CRYPTOLOGY -
>> CRYPTO 2003
>> Lecture Notes in Computer Science, 2003
>> [2] Nikander, P.;   Gurtov, A.;   Henderson, T.R.; Host Identity Protocol
>> (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over
>> IPv4 and IPv6 Networks, Communications Surveys&  Tutorials, IEEE, 2010
>> [3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure Resolution
>> of End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, 2011
>> On 19.12.2011, at 16:51, Rene Struik wrote:
>>
>>
>>  Perhaps, worth some thoughts under the Christmas tree and then getting
>>> back on this one after New Year.
>>>
>>> On 17/11/2011 8:33 PM, Rene Struik wrote:
>>>
>>>> Hi fellow-Rene:
>>>>
>>>> If you have some papers, I would appreciate. Distributing those would
>>>> also help removing hurdles to more wide-scale use of HIP (I saw the slides
>>>> on lack of adoption of HIP).
>>>>
>>>> Best regards, Rene
>>>>
>>>>
>>>> On 14/11/2011 12:49 PM, Rene Struik wrote:
>>>>
>>>>> Hi fellow-Rene:
>>>>>
>>>>> Just curious: is there any research paper outside IETF/IRTF realm that
>>>>> delves into HIP-related matter? On a tangent: same question, but now re
>>>>> cryptographically generated addresses? This may help people to appreciate
>>>>> this effort better, without having to delve into hundreds of pages of
>>>>> specification text that sometimes seems to obscure seeing the forest for
>>>>> the trees (if I translate this properly). I, for one, would love to see 2-3
>>>>> academic papers that make this subject matter clearer, including security
>>>>> properties, ease-of-use considerations.
>>>>>
>>>>> Best regards, Rene
>>>>>
>>>>> On 14/11/2011 12:38 PM, René Hummen wrote:
>>>>>
>>>>>> Hello everyone,
>>>>>>
>>>>>> we already had a few discussions on this list about new topics and
>>>>>> research directions that would foster collaboration within the context of
>>>>>> the hiprg. Hierarchical HITs, IoT-related protocol variants, and middlebox
>>>>>> awareness have been mentioned there among others. In my opinion, an
>>>>>> informal meeting before the hiprg meeting on Thursdays would be a great
>>>>>> opportunity to further discuss about these topics. Furthermore, such a
>>>>>> meeting would enable us see who is interested in which field and which are
>>>>>> the pros and cons of the different topics as perceived by people in a more
>>>>>> comfortable and less hurried way than in an RG meeting.
>>>>>>
>>>>>> As most of us will probably be at the social event tomorrow evening,
>>>>>> I suggest to meet for dinner/a drink on Wednesday evening at 7:30pm in
>>>>>> order to get some discussion going. Due to the lack of knowledge about a
>>>>>> better place, let's meet up at the entrance of the convention center
>>>>>> (TICC). Please email me if you are interested.
>>>>>>
>>>>>> BR
>>>>>> René
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dipl.-Inform. Rene Hummen, Ph.D. Student
>>>>>> Chair of Communication and Distributed Systems
>>>>>> RWTH Aachen University, Germany
>>>>>> tel: +49 241 80 20772
>>>>>> web:
>>>>>> http://www.comsys.rwth-aachen.**de/team/rene-hummen/<http://www.comsys.rwth-aachen.de/team/rene-hummen/>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ______________________________**_________________
>>>>>> hiprg mailing list
>>>>>>
>>>>>> [email-masked]
>>>>>> https://www.irtf.org/mailman/**listinfo/hiprg<https://www.irtf.org/mailman/listinfo/hiprg>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> email:
>>>>> [email-masked]
>>>>>
>>>>> Skype: rstruik
>>>>> cell: +1 (647) 867-5658
>>>>> USA Google voice: +1 (415) 690-7363
>>>>>
>>>>>
>>>>
>>>> --
>>>> email:
>>>> [email-masked]
>>>>
>>>> Skype: rstruik
>>>> cell: +1 (647) 867-5658
>>>> USA Google voice: +1 (415) 690-7363
>>>>
>>>>
>>>
>>> --
>>> email:
>>> [email-masked]
>>>
>>> Skype: rstruik
>>> cell: +1 (647) 867-5658
>>> USA Google voice: +1 (415) 690-7363
>>>
>>>
>>
>>
>>
>> --
>> Dipl.-Inform. Rene Hummen, Ph.D. Student
>> Chair of Communication and Distributed Systems
>> RWTH Aachen University, Germany
>> tel: +49 241 80 20772
>> web: http://www.comsys.rwth-aachen.**de/team/rene-hummen/<http://www.comsys.rwth-aachen.de/team/rene-hummen/>
>>
>>
>>
>>
>> ______________________________**_________________
>> core mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/core<https://www.ietf.org/mailman/listinfo/core>
>>
>
>
>
>
> ---------- Forwarded message ----------
> From: Zach Shelby <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>
> Cc:
> Date: Mon, 2 Jan 2012 16:03:19 +0200
> Subject: [core] Fwd: New Version Notification for
> draft-shelby-core-interfaces-00.txt
> http://www.ietf.org/id/draft-shelby-core-interfaces-00.txt
>
> Here is a new draft that describes a model for REST interface descriptions
> for use with the link format, that I have been using in various contexts
> for a long time. Now I wanted to start developing this further in CoRE -
> please give it a spin in your own server design and will be glad to hear
> feedback and ideas.
>
> Regards,
> Zach
>
> Begin forwarded message:
>
> > From: [email-masked]
> > Date: January 2, 2012 3:59:25 PM GMT+02:00
> > To: [email-masked]
> > Cc: [email-masked]
> > Subject: New Version Notification for draft-shelby-core-interfaces-00.txt
> >
> > A new version of I-D, draft-shelby-core-interfaces-00.txt has been
> successfully submitted by Zach Shelby and posted to the IETF repository.
> >
> > Filename:      draft-shelby-core-interfaces
> > Revision:      00
> > Title:                 CoRE Interfaces
> > Creation date:         2012-01-02
> > WG ID:                 Individual Submission
> > Number of pages: 11
> >
> > Abstract:
> >   This document defines well-known interface descriptions for Batch,
> >   Sensor, Parameter and Actuator types for use in contrained web
> >   servers using the CoRE Link Format.  A short reference is provided
> >   for each type that can be efficiently included in the interface
> >   description attribute of the CoRE Link Format.
> >
> >
> >
> >
> > The IETF Secretariat
>
> --
> Zach Shelby, Chief Nerd, Sensinode Ltd.
> http://www.sensinode.com
> http://zachshelby.org  - My blog "On the Internet of Things"
> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
> Mobile: +358 40 7796297
>
>
>
>
> ---------- Forwarded message ----------
> From: "core issue tracker" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Date: Mon, 02 Jan 2012 16:25:44 -0000
> Subject: [core] #180: Update ABNF for queries
> #180: Update ABNF for queries
>
>  Esko's comments on the link-format document got Zach and me thinking about
>  our usage of ptoken again.
>
>  In link-format-09, the syntax for the queries in the URIs says:
>
>        filter-query = resource-param "=" query-pattern
>        resource-param = "uri" / parmname
>        query-pattern = ptoken [ "*" ]
>        ptoken = <Defined in RFC5988>
>
>  Now, 5988 defines ptoken for use in an RFC822-style (RFC2616) header, not
>  in a URI.
>  Looking more closely:
>
>  ptoken         = 1*ptokenchar
>  ptokenchar     = "!" | "#" | "$" | "%" | "&" | "'" | "("
>                 | ")" | "*" | "+" | "-" | "." | "/" | DIGIT
>                 | ":" | "<" | "=" | ">" | "?" | "@" | ALPHA
>                 | "[" | "]" | "^" | "_" | "`" | "{" | "|"
>                 | "}" | "~"
>
>  Oops, that actually includes "*" and "&"!
>  There also is no mention of percent-encoding (of course not, because
>  RFC2616 does not percent-encode headers).
>
>  So what we really want to import here is RFC3986 ABNF, not RFC2616/RFC5988
>  ABNF.
>
>  First attempt:
>
>        query-pattern = search-token [ "*" ]
>        search-token = *pchar
>
>  But pchar (RFC3986) includes subdelims:
>
>   pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
>
>   query         = *( pchar / "/" / "?" )
>
>   pct-encoded   = "%" HEXDIG HEXDIG
>   unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
>   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
>                 / "*" / "+" / "," / ";" / "="
>
>  … which includes "*" and "&".
>
>  So, to do this right, let's mix this properly:
>
>        query-pattern = search-token [ "*" ]
>        search-token = *search-char
>        search-char = unreserved / pct-encoded
>                    / ":" / "@"   ; from pchar
>                    / "/" / "?"   ; from query
>                    / "!" / "$" / "'" / "(" / ")"
>                    / "+" / "," / ";" / "="  ; from sub-delims
>
>
>  :@/?!$'()+,;= indeed.
>
>
>  This makes it possible to say something like:
>
>  GET /.well-known/core?rt=outdoor%20temperature
>
>  After the percent-decoding defined in core-coap's URI parsing (section
>  6.4), the server will see:
>
>  Uri-Path  .well-known
>  Uri-Path  core
>  Uri-Query rt=outdoor temperature
>
>  which sounds about right.
>
>  The parser in the server will now just have to
>  1) search for the first "=" and use that to delimit the parameter name
>  from the search-token
>  2) check for a trailing "*" and remove that, if present, indicating a
>  prefix match.
>
>  Would I use spaces for rt values?  Probably not, but there are still good
>  reasons for staying general here.
>  As the percent-decoding is already done when the server sees it, there is
>  no cost to this generality, either.
>
>  The defnition of query-pattern also needs to be updated.
>
> --
> -------------------------+--------------------
>  Reporter:  zach@…       |      Owner:  zach@…
>     Type:  editorial    |     Status:  new
>  Priority:  minor        |  Milestone:
> Component:  link-format  |    Version:
>  Severity:  -            |   Keywords:
> -------------------------+--------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/180>
> core <http://tools.ietf.org/core/>
>
>
>
>
> ---------- Forwarded message ----------
> From: "core issue tracker" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Date: Mon, 02 Jan 2012 16:35:09 -0000
> Subject: Re: [core] #178: Multiple relation types
> #178: Multiple relation types
>
>
> Comment (by zach@…):
>
>  Done.
>
> --
> ----------------------------------+---------------------
>  Reporter:  zach@…                |       Owner:  zach@…
>     Type:  protocol enhancement  |      Status:  new
>  Priority:  minor                 |   Milestone:
> Component:  link-format           |     Version:
>  Severity:  -                     |  Resolution:
>  Keywords:                        |
> ----------------------------------+---------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/178#comment:1>
> core <http://tools.ietf.org/core/>
>
>
>
>
> ---------- Forwarded message ----------
> From: "core issue tracker" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Date: Mon, 02 Jan 2012 16:35:20 -0000
> Subject: Re: [core] #178: Multiple relation types
> #178: Multiple relation types
>
> Changes (by zach@…):
>
>  * status:  new => closed
>  * resolution:   => fixed
>
>
> --
> ----------------------------------+---------------------
>  Reporter:  zach@…                |       Owner:  zach@…
>     Type:  protocol enhancement  |      Status:  closed
>  Priority:  minor                 |   Milestone:
> Component:  link-format           |     Version:
>  Severity:  -                     |  Resolution:  fixed
>  Keywords:                        |
> ----------------------------------+---------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/178#comment:2>
> core <http://tools.ietf.org/core/>
>
>
>
>
> ---------- Forwarded message ----------
> From: "core issue tracker" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Date: Mon, 02 Jan 2012 16:38:18 -0000
> Subject: Re: [core] #179: SHOULD NOT for multicast response repression
> #179: SHOULD NOT for multicast response repression
>
> Changes (by zach@…):
>
>  * status:  new => closed
>  * resolution:   => fixed
>
>
> Comment:
>
>  Done:
>
>  "When using a transfer protocol like the Constrained Application Protocol
>  (CoAP) that supports multicast requests, special care is taken. A
>  multicast request with a query string SHOULD NOT be responded to if
>  filtering is not supported or if the filter does not match (to avoid a
>  needless response storm). The exception is in cases where the IP stack
>  interface is not able to indicate that the source address was multicast."
>
> --
> ----------------------------------+---------------------
>  Reporter:  zach@…                |       Owner:  zach@…
>     Type:  protocol enhancement  |      Status:  closed
>  Priority:  minor                 |   Milestone:
> Component:  link-format           |     Version:
>  Severity:  -                     |  Resolution:  fixed
>  Keywords:                        |
> ----------------------------------+---------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/179#comment:1>
> core <http://tools.ietf.org/core/>
>
>
>
>
> ---------- Forwarded message ----------
> From: "core issue tracker" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Date: Mon, 02 Jan 2012 16:41:54 -0000
> Subject: Re: [core] #180: Update ABNF for queries
> #180: Update ABNF for queries
>
> Changes (by zach@…):
>
>  * status:  new => closed
>  * resolution:   => fixed
>
>
> Comment:
>
>  Done.
>
> --
> -------------------------+---------------------
>  Reporter:  zach@…       |       Owner:  zach@…
>     Type:  editorial    |      Status:  closed
>  Priority:  minor        |   Milestone:
> Component:  link-format  |     Version:
>  Severity:  -            |  Resolution:  fixed
>  Keywords:               |
> -------------------------+---------------------
>
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/180#comment:1>
> core <http://tools.ietf.org/core/>
>
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 11 Jan 2012 22:06:44 +0200

Hi Antonio,

On Jan 4, 2012, at 4:22 PM, Antonio Jara wrote:

> Hi Zach,
> 
> Regarding the integration of sensors/actuator from legacy technologies and protocols which are being adapted to 6LoWPAN/IPv6. For example, in building automation a EIB/KNX device or X10 device, which is integrated in a gateway to be enabled/powered with CoAP and IPv6 access.

Yes, Peter's draft on building automation also touches on this subject. 

> The description of this interfaces in the gateway for the DNS-SD could be core#x10_s or something like that. Or this specification of the technology is more focused on the "resource type" parameter that in the "interface" one.

The interface description really should describe the REST interface of that resource. So what you put there depends on how you map the legacy technology to resources. To me it sounds like the resource type parameter would be most useful for describing that this resource has something to do with X10, and to discover it. 

You might want to just try creating some REST mappings for those kinds of legacy devices, and then take a shot at naming them after that. 

Zach

> Subject: Re: [core] [hiprg] Research topics discussion - meeting suggestion: Wednesday 7:30pm
> Hi,
> 
> I sent privately a number of references for Struik but here's the most essential ones. Regarding to ease-of-use considerations, and UIA [1] extends HIP-like security to user-level identities. We have also conducted some usability tests with a HIP GUI [2] earlier.
> 
> Regarding to security, references [3,4] are worth checking out because they have helped to improve the security in HIP.
> 
> [1] http://www.pdos.lcs.mit.edu/papers/uia:osdi06.pdf
> 
> [2] Kristiina Karvonen, Miika Komu and Andrei Gurtov, Usable Security Management with Host Identity Protocol, published in The 7th ACS/IEEE International Conference on Computer Systems and Applications (AICCSA-2009)
> 
> this email contains a few references to papers regarding the security properties and embedding of HIP in today's network environments.
> 
> First of all, HIP is a SIGMA-compliant key exchange protocol [1]. To be exact, it is a derivate of the basic protocol described in Section 5.1, as the HIP BEX is triggered by a separate (empty) message that is not included in the SIGMA protocol family. This allows HIP to perform DoS protection against exhaustive public key-based operations by the responder by means of cryptographic puzzles. Furthermore, the public key (A) of the responder is already sent in the first response message. However, this does not impact the security properties, but rather the anonymity of the responder.
> 
> Regarding the usage of HIP, there is a rather comprehensive journal article [2] that describes the architecture as well as the operation system and infrastructure requirements of HIP. It also provides some pointers to further papers that may be worth reading for you. Additionally, Samu Varjonen recently published a paper on the "Secure Resolution of End-Host Identifiers for Mobile Clients" [3]. However, it seems to be inaccessible at the moment. Still, you may want to refer to it at later point in time, as it describes an approach to resolve HITs to IP addresses.
> 
> I hope that this small selection is helping you in understanding the properties of HIP. I would also like to invite other people to contribute to this discussion, e.g., by providing further references relevant for the CoRE WG.
> 
> Regards,
> René
> 
> 
> [1] Krawczyk, H.; SIGMA: The ‘SIGn-and-MAc’ Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols, ADVANCES IN CRYPTOLOGY - CRYPTO 2003
> [2] Nikander, P.;   Gurtov, A.;   Henderson, T.R.; Host Identity Protocol (HIP): Connectivity, Mobility, Multi-Homing, Security, and Privacy over IPv4 and IPv6 Networks, Communications Surveys&  Tutorials, IEEE, 2010
> [3] Varjonen, S.; Heer, T.; Rimey, K.; and Gurtov, A.; Secure Resolution of End-Host Identifiers for Mobile Clients, IEEE GLOBECOM, 2011
> Perhaps, worth some thoughts under the Christmas tree and then getting back on this one after New Year.
> 
> If you have some papers, I would appreciate. Distributing those would also help removing hurdles to more wide-scale use of HIP (I saw the slides on lack of adoption of HIP).
> 
> Best regards, Rene
> 
> 
> Just curious: is there any research paper outside IETF/IRTF realm that delves into HIP-related matter? On a tangent: same question, but now re cryptographically generated addresses? This may help people to appreciate this effort better, without having to delve into hundreds of pages of specification text that sometimes seems to obscure seeing the forest for the trees (if I translate this properly). I, for one, would love to see 2-3 academic papers that make this subject matter clearer, including security properties, ease-of-use considerations.
> 
> Best regards, Rene
> 
> we already had a few discussions on this list about new topics and research directions that would foster collaboration within the context of the hiprg. Hierarchical HITs, IoT-related protocol variants, and middlebox awareness have been mentioned there among others. In my opinion, an informal meeting before the hiprg meeting on Thursdays would be a great opportunity to further discuss about these topics. Furthermore, such a meeting would enable us see who is interested in which field and which are the pros and cons of the different topics as perceived by people in a more comfortable and less hurried way than in an RG meeting.
> 
> As most of us will probably be at the social event tomorrow evening, I suggest to meet for dinner/a drink on Wednesday evening at 7:30pm in order to get some discussion going. Due to the lack of knowledge about a better place, let's meet up at the entrance of the convention center (TICC). Please email me if you are interested.
> 
> BR
> René
> 
> 
> 
> --
> http://www.comsys.rwth-aachen.de/team/rene-hummen/
> 
> 
> 
> 
> 
> https://www.irtf.org/mailman/listinfo/hiprg
> 
> 
> --
> email:
> [email-masked]
> 
> Skype: rstruik
> cell: +1 (647) 867-5658
> web: http://www.comsys.rwth-aachen.de/team/rene-hummen/
> 
> 
> 
> 
> Subject: [core] Fwd: New Version Notification for draft-shelby-core-interfaces-00.txt
> Here is a new draft that describes a model for REST interface descriptions for use with the link format, that I have been using in various contexts for a long time. Now I wanted to start developing this further in CoRE - please give it a spin in your own server design and will be glad to hear feedback and ideas.
> 
> Regards,
> Zach
> 
> Begin forwarded message:
> 
> > A new version of I-D, draft-shelby-core-interfaces-00.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> >

---

From: "Stok, Peter van der" <[email-masked]>
Date: Thu, 12 Jan 2012 11:44:54 +0000

Hi Zach and Antonio,

I am quite pleased that there is an interest in legacy devices and service descriptions.
What I miss is a few lines on how this may complement service description efforts by SDOs.
For example CABA and later OASIS have invested in the Obix standard, ZigBee has invested in the SE2 service descriptions, DNX was extended to ACN, ..
and other SDOs are making similar efforts.

Looking forward to read your view,

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: Wednesday 11 January 2012 21:07
To: Antonio Jara
Cc: [email-masked]
Subject: Re: [core] New Version Notification for draft-shelby-core-interfaces-00.txt

Hi Antonio,

Zach

> [1] Krawczyk, H.; SIGMA: The 'SIGn-and-MAc' Approach to Authenticated Diffie-Hellman and Its Use in the IKE Protocols, ADVANCES IN CRYPTOLOGY - CRYPTO 2003
>  ... which includes "*" and "&".
>
>  Reporter:  zach@...       |      Owner:  zach@...
> Comment (by zach@...):
>  Reporter:  zach@...                |       Owner:  zach@...
> Changes (by zach@...):
>  Reporter:  zach@...                |       Owner:  zach@...
> Changes (by zach@...):
>  Reporter:  zach@...                |       Owner:  zach@...
> Changes (by zach@...):
>  Reporter:  zach@...       |       Owner:  zach@...

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Zach Shelby <[email-masked]>
Date: Thu, 12 Jan 2012 17:29:13 +0200

> and other SDOs are making similar efforts.

These are by no means legacy, and already make use of REST. For example SE2 has service types that we can already make use of in Resource Type fields in link descriptions (we have already defined this for SE2). Although oBix doesn't have this defined, it would be straightforward to assign a Resource Type to identify oBix resources or make a URI reference (we are working on that in an EU project). DNX/ACN I am not familiar with. 

I think this is more difficult for legacy technologies, where a REST mapping needs to be defined in the first place in addition to resource naming. 

Zach