Clarification on encoding format of attachment data in Delivery message of RFC-0685-pickup-v2

[nain-F49FF806]

Is the last line here (emphasis mine), meant to imply that only base64 encoding is valid in delivery message attachments (as opposed to json/links defined in attachment rfc)?

It is unclear if the final line there implies a recommendation/compulsion of the protocol RFC to use the shown encoding, or is simply a comment for the particular example.

Source partially quoted below for convenience.

The ONLY valid type of attachment for this message is a DIDComm Message in encrypted form.

The recipient_key attribute is only included when responding to a delivery-request message that indicates a recipient_key.

{
    "@id": "123456781",
    "~thread": {
        "thid": "<message id of delivery-request message>"
      },
    "@type": "https://didcomm.org/messagepickup/2.0/delivery",
    "recipient_key": "<key for messages>",
    "~attach": [{
    	"@id": "<messageid>",
    	"data": {
    		"base64": ""
    	}
    }]
}

This method of delivery does incur an encoding cost, but is much simpler to implement and a more robust interaction.

[genaris]

My understanding is that both base64 and json forms are valid (links are theoretically valid as well, but I don't see any meaningful use case for them). In Credo we are sending them in json format, but we accept receiving them also in base64.

To my kowledge, the line:

This method of delivery does incur an encoding cost, but is much simpler to implement and a more robust interaction.

Refers to the fact that wrapping Forward messages in a Delivery message is more costly than simply sending them 'naked' through the transport.

@TelegramSam considering that we are going to add some clarifications on this spec, I think it's worth to also add a note here.