Re: [dtn] Alert-Verify-Sender: Re: [EXT] Re: Status of AUTH48 Documents (and a request)

[[e-mail]]

All,

sorry, please disregard my comment, I have just realised it is nonsense 
(the break stop code could help a bit but, of course, it would not be 
reliable).

Regards,
Felix



From:   [e-mail]
To:     "Sipos, Brian J." <[e-mail]>, "Carsten Bormann" 
<[e-mail]>, "Birrane, Edward J." <[e-mail]>
Cc:     "[e-mail]" <[e-mail]>
Date:   13/12/2021 08:40
Subject:        Re: [dtn] Alert-Verify-Sender: Re: [EXT] Re: Status of 
AUTH48 Documents (and a request)
Sent by:        "dtn" <[e-mail]>



All, 

I would be in favour of the statement "except that an indefinite-length 
array item is allowed to represent the array of blocks in the bundle..." 
with a clear understanding that the array of bundle blocks is the only 
indefinite-length item in any bundle (i.e., also future extension blocks). 
This would allow to use the break stop code to reliably identify the end 
of a bundle in a stream of bytes. 

(Maybe even 'allowed' it to weak in this case and could be replaced by 
'mandatory'.) 

Regards,
Felix 





From:        "Sipos, Brian J." <[e-mail]> 
To:        "Birrane, Edward J." <[e-mail]>, "Carsten 
Bormann" <[e-mail]> 
Cc:        "[e-mail]" <[e-mail]> 
Date:        10/12/2021 19:54 
Subject:        Re: [dtn] Alert-Verify-Sender: Re: [EXT] Re: Status of 
AUTH48 Documents (and a request) 
Sent by:        "dtn" <[e-mail]> 



All,
I agree with making the deterministic encoding a normative statement and I 
expect that current encoders are already adhering to this.
BPv7 can, and other specs do, make a blanket statement like that and leave 
a specific hole for the (currently one) exceptional case. The document can 
say, as you have said, that "... core deterministic encoding requirements 
as specified in [RFC8949], except where indefinite-length items are 
required (i.e. the bundle container array)."

-----Original Message-----
From: dtn <[e-mail]> On Behalf Of Birrane, Edward J.
Sent: Friday, December 10, 2021 1:12 PM
To: Carsten Bormann <[e-mail]>
Cc: [e-mail]
Subject: Alert-Verify-Sender: Re: [dtn] [EXT] Re: Status of AUTH48 
Documents (and a request)

APL external email warning: Verify sender [e-mail] before 
clicking links or attachments 

Carsten,

 A few items:

- There are no maps defined for any field of any block in the bundle 
protocol.
- There are many instances where arrays are defined, but in each instance 
the exact number of array elements is also provided with the exception of 
the bundle itself, which is an indefinite-length array of blocks.
- The are two instances of byte string which either specify the size of 
the byte string (as in CRC) or require that the byte string be definite 
length (as in the block-type-specific data field of an extension block).

Perhaps your point is that saying "a CBOR array of length X" does not 
explicitly say "a definite-length encoding of a CBOR array of length X". 
Which makes sense.

To that point, perhaps the more concise statement for 9171 would be 
"except that an indefinite-length array item is allowed to represent the 
array of blocks in the bundle..."

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his) Chief Engineer, Space 
Constellation Networking Space Exploration Sector Johns Hopkins Applied 
Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
 


> -----Original Message-----
> From: Carsten Bormann <[e-mail]>
> Sent: Friday, December 10, 2021 12:49 PM
> To: Birrane, Edward J. <[e-mail]>
> Cc: [e-mail]
> Subject: [EXT] Re: [dtn] Status of AUTH48 Documents (and a request)
> 
> APL external email warning: Verify sender [e-mail] before clicking 
> links or attachments
> 
> Hi Ed,
> 
> On 2021-12-10, at 18:30, Birrane, Edward J. 
> <[e-mail]>
> wrote:
> >
> > "To ensure that blocks are always in canonical representation when 
> > they
> are transmitted and received, the CBOR encodings of the values of all 
> fields in all blocks MUST conform to the core deterministic encoding 
> requirements as specified in [RFC8949], except that indefinite-length 
> items are not prohibited.?
> 
> So you still provide for different representations for all arrays, 
> maps, and (byte or text) strings?  I?m not sure I know what ?canonical? 
means (or really:
> is trying to achieve) here, but maybe you want to be more specific 
> about
> *where* the indefinite length encoding is permissible (and maybe even
> *require* it in those places, so there is only one, er, ?canonical?, 
form).
> 
> Grüße, Carsten

_______________________________________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dtn
[attachment "smime.p7s" deleted by Felix Flentge/esoc/ESA] 
_______________________________________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dtn

[attachment "smime.p7s" deleted by Felix Flentge/esoc/ESA] 
_______________________________________________
dtn mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dtn