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

[Marc Blanchet <[e-mail]>]

> Le 18 janv. 2023 à 20:16, Stephen Farrell <[e-mail]> a écrit :
> 
> Hiya,
> 
> On 19/01/2023 00:16, Marc Blanchet wrote:
>> 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, 
> 
> That's fine. I don't think I criticised the draft text at
> all,

All fine, I did not interpret that way. I was trying to sell my draft ;-)

> I'm rather asking whether stepping back first to discuss the bigger picture first is better. (And I think it is.)
> 
>> 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.
> 
> I guess I disagree there. ISTM that a better starting point
> would be to figure out what needs to be standardised. And my
> bet FWIW (and it's not worth much:-) is that miinimising the
> bandwidth required while allowing users access to their
> message stores is likely more pressing.

Given current usage (almost illimited) with very large message store (because cloud disk space is so cheap, that people are not cleaning their mailbox), having any kind of sync solution of mail stores is dangerous: yes one can restrict to the last x days or last y messages, but again dangerous. I’m not sure it is worth. What I’m proposing is to me more reliable in the sense that stuff happening on the planetary body remains on the planetary body (looks like a statement similar to another one ;-) and that way no dependencies.

> 
> I'd also wonder whether an MTA-MTA SMTP/dtn encapsulation
> would be better with one mail/bundle or not. I can envisage
> scenarios where mail submission to 587 might well result in
> one mail/bundle being emitted for sure, but that might not be
> that common - hard to tell at this point.
> 
> So don't take me as opposing your draft

I did take that.  But I’m also here to argue ;-)

> - I think it's a good
> discussion to have and your -00 is a fine start for that.

Yeap. Also make it to me clear we need some f2f high-bandwidth-low-latency meeting time to discuss that. 
Chairs, haven’t seen any ack on my request?

Marc.

> 
> Cheers,
> S.