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

Marc Blanchet <marc.blanchet@viagenie.ca> Mon, 30 January 2023 03:43 UTC

Return-Path: <marc.blanchet@viagenie.ca>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CE2C14CF18 for <dtn@ietfa.amsl.com>; Sun, 29 Jan 2023 19:43:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=viagenie-ca.20210112.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFumPb41GIyg for <dtn@ietfa.amsl.com>; Sun, 29 Jan 2023 19:43:38 -0800 (PST)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12097C14F726 for <dtn@ietf.org>; Sun, 29 Jan 2023 19:43:37 -0800 (PST)
Received: by mail-qt1-x831.google.com with SMTP id d3so8989561qte.8 for <dtn@ietf.org>; Sun, 29 Jan 2023 19:43:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=viagenie-ca.20210112.gappssmtp.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qV6TyP4991UQEMVYoYDjyzmWvUjxIcgTjGT21EDI6LE=; b=MQXVy6PvJxfkh4L7V37Aoq9t+WsXJS9qPQrzsEc7JHPuZgTvDIIJHPtsG2V8IcOEiy dWVGfUdyatRVxzYYZ7b23wKXNGW+Kp3KSsvzxMpvdyRt4etYe+8pclPglrJCPcIzjkKA eHt/YmpPIhUN5l5Zi8Wd0g4YmV7D7XkDaNL9Un++ep28nX5uoKE90TxHbp4lxhPAuYXf m+kWe6acDjiSOJ5NuLytbYbdqzICLHVvhfq+Bd0pHWVkw5ZqK7evdo++4mS1q2WV7EpU kxSLDJgkPHwmIJAvvjKHD2WVWwmt+7qBJBfBJ3IJHXTIy8pAnjs7+Mf5a65HqCzn+k40 JdpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qV6TyP4991UQEMVYoYDjyzmWvUjxIcgTjGT21EDI6LE=; b=TtGFIy5eQQUz/glwV/7nnJlqKMX98wq+d8xSu02yymB5+hCttKHmumfsTc6s3Aw8IU oOAkvMYvyTD7vRh1OJbMqbX+CeqkUlBf/TeQ5g3YM7bsg9hJollYYfyVvDo/NGgbZppX yO13Goq4Uv3p/fpR9GNHItKyCGZr/J5lpm0s6UEp5HFuYw3Ezlz8Q5goa9d9yBTpi8jb AAJv37RRsvJ7HWb5hbfODUWLE12mR9JUrvIKUFD600ZlVOCFbSPGC6knHq8tMtQOKmgk plACYb95N0OUOETpI4vBa117r/UUka/+naQ76OCrEBmYEEuR86d8nElQOzYtdkYZeDWd dOgQ==
X-Gm-Message-State: AO0yUKXT9AhbzNDAihh76jhuIDKpm9mSRCvwQJ7aZNe6kDZQjbYFX+Wh tjg4u5Sroxzc7Q7VyxMWce6xjhD3FMSh2sLcmBg=
X-Google-Smtp-Source: AK7set/DodEMUeVWs24XqpKobFii9C2ON4dOSAO5m2W4d0qt8cwbJIG3tx4r0ztuvLsoskPfsvGDQw==
X-Received: by 2002:a05:622a:188a:b0:3b8:2175:fcff with SMTP id v10-20020a05622a188a00b003b82175fcffmr18978158qtc.31.1675050216669; Sun, 29 Jan 2023 19:43:36 -0800 (PST)
Received: from smtpclient.apple (modemcable161.124-162-184.mc.videotron.ca. [184.162.124.161]) by smtp.gmail.com with ESMTPSA id c16-20020ac80090000000b003b323387c1asm7306453qtg.18.2023.01.29.19.43.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Jan 2023 19:43:35 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <867a89b2207a4dc2a659d7a0f13578eb@jhuapl.edu>
Date: Sun, 29 Jan 2023 22:43:24 -0500
Cc: DTN WG <dtn@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <093235F8-69ED-4F7C-ABA0-3875B50A3F61@viagenie.ca>
References: <167399610126.6093.15005582259524860869@ietfa.amsl.com> <E73A1CD3-88A6-4ECB-90A1-ACD5150F9E05@viagenie.ca> <51483b79-1ccf-49ab-514a-f0610d2e1bfb@cs.tcd.ie> <92e3c78f8bc44beb9050302df536b454@jhuapl.edu> <D4C71029-FCA5-4C5E-894D-5EFF9AE321D8@viagenie.ca> <867a89b2207a4dc2a659d7a0f13578eb@jhuapl.edu>
To: "Birrane, Edward J." <Edward.Birrane@jhuapl.edu>
X-Mailer: Apple Mail (2.3731.300.101.1.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/1SOe1YTrK3iwEZFz2eZbEq4qBXg>
Subject: Re: [dtn] [EXT] draft-blanchet-dtn-email-over-bp-00.txt
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2023 03:43:42 -0000

> Le 29 janv. 2023 à 17:26, Birrane, Edward J. <Edward.Birrane@jhuapl.edu> a écrit :
> 
> 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?

It is interesting that you are saying that, because an approach similar to what you are describing is described in the draft-blanchet-dtn-bp-application-framework, as I was envisioning multiple kind of payloads with some tagging (mime types). I requested during the last meeting about if there were interest in this, but now we can discuss ;-)

However, if you take the perspective of a developer, having just an IANA entry is way not enough. There are multiple questions to answer related to properly work with email. I think the document is required to say those. I’m having a new local version that is talking about more considerations as I’ve been discussing with email experts. Shall post sometimes soon. 

> 
>>> 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.

If we go further, then we would be encoding every single application with a specific code point or extension block. Seems way complicated to me. My take is we shall not continue to complexify BP. My humble experience with IP is that simpler it is, better it flies over time.

> 
>> 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. 

Will look into RFC6854, but RFC5322 is really the master piece here.

> 
> 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?

No. Again, images, audio, media, files, … are _all_ handled with MIME within the content.  But your question is very legitimate. Will add some text about that. But I think your comment  just shows that we really need a document to talk about those instead of just an IANA entry, as you suggested above.

Marc.


> 
> 
>