Re: [core] multipart/core

On Jun 6, 2018, at 11:14, Peter van der Stok <stokcons@bbhmail.nl> wrote:
> 
> Hi Jaime,
> 
> The draft est-coaps is an ACE WG draft
> The multipart core is a personal draft; not CoRE yet.
> I would be very much reassured if the WG adoption of multipart core takes place shortly.
> 
> The WGLC of est-coaps may well be around ietf102.

Right, and there is little reason to wait finishing multipart/core until est-coaps is finished.
The idea of multipart/core is really well-aged now; I think the only reason why we haven’t written it down yet was that we didn’t have a use case.
Now we seem to have two, and we should be able to go ahead with multipart/core very quickly.

Grüße, Carsten

> 
> greetings,
> 
> Peter
> Jaime Jiménez schreef op 2018-06-06 11:10:
> 
>> Hi Michael,
>>  
>> the draft does indeed pretty straightforward and short, EST-COAP is not yet in WCLC or similar but if the ACE Chairs have some deadline in mind please let us know, to give enough time to the group to move this document forward.
>>  
>> Ciao,
>> - - Jaime Jiménez
>> 
>>> On 5 Jun 2018, at 20.49, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>>> 
>>> Jaime...
>>> 
>>> Carsten, Thomas and Klaus have just updated:
>>>   <https://tools.ietf.org/html/draft-fossati-core-multipart-ct-04>
>>> which says very succintly:
>>> 
>>>   The collection is encoded as a CBOR [RFC7049] array with an even
>>>   number of elements.  The second, fourth, sixth, etc. element is a
>>>   byte string containing a representation, or the value "null" if an
>>>   optional part is indicated as not given.  The first, third,
>>>   fifth, etc. element is an unsigned integer specifying the content format ID
>>>   of the representation following it.
>>> 
>>>   For example, a collection containing two representations, one with
>>>   content format ID 42 and one with content format ID 0, looks like
>>>   this in CBOR diagnostic notation:
>>> 
>>>      [42, h'0123456789abcdef', 0, h'3031323334']
>>> 
>>> 
>>> EST-COAP (in the ACE WG) needs a multipart reply for the corner case of
>>> server generated (private) keys. Servergen is supported in RFC7030, greatly
>>> desired by some parties, although some parties deem it a mis-feature.
>>> 
>>> I can't see anything wrong with the draft as it is, and I'd like to see it
>>> quickly adopted and WGLC'ed....
>>> 
>>> -- 
>>> ]               Never tell me the odds!                 | ipv6 mesh networks [ 
>>> ]   Michael Richardson, Sandelman Software Works        | network architect  [ 
>>> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
>>>  
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>> 
>> _______________________________________________
>> core mailing list
>> core@ietf.org
>> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core