Re: [dtn] draft-blanchet-dtn-email-over-bp-00.txt

> Le 18 janv. 2023 à 15:44, Stephen Farrell <stephen.farrell@cs.tcd.ie> a écrit :
> 
> 
> Hiya,
> 
> On 18/01/2023 19:05, Marc Blanchet wrote:
>> Read your [2] paper. Very interesting, very detailed. About mail, you
>> used a process that look at changes in the mailbox directories of
>> users, tar them in a tar file that is put into bundle(s). The other
>> endpoint does the reverse. I’m fine with this as a research trial but
>> I’m not sure it is really what we are looking for, in terms of
>> interoperability. Both endpoints need to support the same tar +
>> maildir formats, I’m not sure that will work with commercial email
>> systems for example. The solution I’m proposing is to use very very
>> standard format of RFC822 much easier to integrate with any MTA,
> 
> So, yes if one were suggesting to standardise a form of MS
> sync over dtn, then more would be needed than we did and it'd
> need to be supported by both sides of course, same as any
> protocol.
> 
> Providing a way to encapsulate a message in a bundle is
> likely needed anyway, to handle mail submission, but is very
> much not sufficient to claim to be providing mail/dtn.
> 
> Whether or not the mail is for humans, whether the same MUA
> on a mobile device in different dtn regions needs to be
> supported, whether account creation needs to be supported,
> whether using a standard MUA is a requirement etc. are IMO
> questions to ask before figuring out what to standardise.

Wait. The draft says clearly about the actual scenario.  And it also says that “operational” considerations such as many you write above are not discussed, as I see this (important) discussion going elsewhere (either an operational document or at another forum). This draft is about encapsulation of email RFC822 into bundles. Nothing more, Nothing less. And standard MTA are able to read that format! “Everything else” (such as MUA, …), are to me outside the scope of the document as a protocol spec.

Marc.

> 
> And yes, some of the stuff we did a decade ago would be
> impacted by e.g. the prevalence today of IMAP/TLS, DKIM and
> DMARC etc that weren't as deployed back then but are a
> baseline now.
> 
> Bottom line for me is to start by asking what's required,
> for whom, in what kind(s) of dtn, which does seem to me like
> a fun discussion if there're real use cases for this.
> 
> Cheers,
> S.
> 
> 
> 
>> since that format is the primary exchange format for the last 40
>> years… It is also not dependent on any sync mechanism which sometimes
>> goes out of sync and require pretty significant handling of errors of
>> synchronisation. My proposal is almost as if two MTA are on the same
>> machine and exchange email using RFC822 format in a very simple
>> interprocess communication, but that interprocess communication is
>> actually a BP “pipe”.
>> Regards, Marc.
>>> Le 18 janv. 2023 à 07:52, Stephen Farrell
>>> <stephen.farrell@cs.tcd.ie> a écrit :
>>> Hiya,
>>> On 18/01/2023 00:29, Marc Blanchet wrote:
>>>>> Sorry, no. I can probably try dig up some paper but forget how
>>>>> much implementation detail we documented. Will look in the
>>>>> morning (here:-)
>>>> Great. Looking forward.
>>> It's been quite a while since I looked back at that stuff sorry, so
>>> best I can find is from about a year or so before the mail stuff
>>> fully worked. There's one paper [1] that may be paywalled, (if so,
>>> [2] is not). There's a section in there on "Email service." IIRC we
>>> extended that some in subsequent summers.
>>> Cheers, S.
>>> [1] https://link.springer.com/article/10.1007/s11276-011-0323-1 [2]
>>> https://down.dsg.cs.tcd.ie/summer09paper/summer09paper/summer09.pdf
>>> 
> <OpenPGP_0x5AB2FAF17B172BEA.asc>
>> _______________________________________________ dtn mailing list dtn@ietf.org https://www.ietf.org/mailman/listinfo/dtn
> <OpenPGP_0x5AB2FAF17B172BEA.asc>