Re: [dtn] Alert-Verify-Sender: Re: [EXT] draft-blanchet-dtn-email-over-bp-00.txt

Marc,

  Minor typo in my response below:

s/RFC7254/RFC6854/

not sure why I typed RFC7254....my apologies.

-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: dtn <dtn-bounces@ietf.org> On Behalf Of Birrane, Edward J.
> Sent: Sunday, January 29, 2023 5:26 PM
> To: Marc Blanchet <marc.blanchet@viagenie.ca>
> Cc: DTN WG <dtn@ietf.org>
> Subject: Alert-Verify-Sender: Re: [dtn] [EXT] draft-blanchet-dtn-email-over-
> bp-00.txt
> 
> APL external email warning: Verify sender dtn-bounces@ietf.org before
> clicking links or attachments
> 
> Marc,
> 
>   Thank you for this response, and for starting the conversation!
> 
>  My replies (prepended with EJB:) below.
> 
> -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
> 
> > >  The -00 draft says to put an e-mail into a bundle as a bundle
> > > payload - do
> > we need a normative RFC to say that?
> >
> > I guess I don’t understand your question, because my response as I
> > understand your question is: well, that is the whole purpose of the
> > draft. But I’m sure I’m not answering your question. Can you clarify?
> 
> EJB: Since the draft does not suggest any modifications to RFC5322 messages
> or to the bundle itself, would this approach be better communicated as an
> entry in a service number registry?  For example, if we added an entry in the
> CBHE service numbers registry
> (https://www.iana.org/assignments/bundle/bundle.xhtml#cbhe-service-
> numbers) with an entry of: Value="<some number>",  Description=
> "Unmodified Internet Message Format Text" and Reference="RFC5322" are
> we done? Would we need anything else?
> 
> 
> > >  Should we explore how features of BP (such as extension blocks)
> > > could
> > help with e-mail delivery? Could there be benefit to pulling some
> > header/ address information into an extension block?
> >
> > Does not make sense to me. Can you elaborate?
> 
> EJB: One of the potential benefits of extension blocks in BP is to carry
> annotative information about the payload, so that the bundle can be handled
> without needing to deep-inspect the payload. This is especially true if the
> payload is end-to-end encrypted. I defer to the WG on whether there is any
> value to that approach when using RFC5322 payloads.
> 
> > Attachments, encryption and signature of emails are all handled within
> > the body of the email, so this is all included and working by RFC5322.
> > I’ll add a note in the next rev.
> 
> EJB: RFC5322 Section 1.1 states "This document specifies a syntax only for
> text messages.  In  particular, it makes no provision for the transmission of
> images,  audio, or other sorts of structured data in electronic mail
> messages.".  Further, it seems that RFC6854 updates RFC5322 to allow group
> syntax in the From: and Sender: fields.
> 
> EJB: I think my question is: When you specified RFC5322 (instead of RFC7254
> or any RFCs relating to MIME) was that to intentionally limit the kinds of
> payloads carried in the bundle or to otherwise prevent group messaging?
> 
> 
> 
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn