Attachment x-label property - who is setting it

[rogercreagh]

When I read items from the Nextcloud server any attachment (embedded or link) has FILENAME and X-LABEL properties. The filename part is set to the filename of the embedded or linked file
(for embedded attachments ENCODING, VALUE, and FMTTYPE are also set)
X-LABEL is set to be the same as the filename.

My question is who is setting the X-LABEL value?

There doesn't seem to be any way of editing it in jtxB, Nextcloud calendar doesn't seem to set or recognise attachments (in Vevents) and Thunderbird will only attach weblinks to calendar entries and doesn't set any properties on them - just ATTACH:url

If X-LABEL is being set by jtxB how can we edit it?

[patrickunterwegs]

Hey @rogercreagh ,
I can give you a more profound answer later, but now in short:
I believe I used both parameters because both are in use. If I remember correctly it was especially a thing for Gnome Evolution and KOrganizer, the one application uses X-LABEL, the other FILENAME. It's true that it is not so nice, but it ensured compatibility.

Generally attachments require a bit more discussion in the future. I was also discussing with DAVx5 as currently all attachments are either links or inline attachments. It would be nice to have managed attachments for remote collections, so that when you add an attachment, the attachment gets uploaded to the server and the inline attachment gets replaced by a secured link on the server. But that's something for the future...

[rogercreagh]

Thanks; so whichever is using X-LABEL is expecting a filename there?
If so that's a shame as a human readable name for the attachment would be quite useful (not that filenames aren't readable, but they are sometimes obscure X-LABEL="Photo of the cake";FILENAME="20220505-172450_TZ70a.JPG" would be better)

[patrickunterwegs]

Yes, X-LABEL is supposed to contain the filename.
But I'm with you. If you're thinking about also using attachments, we could also agree on removing the X-LABEL and only keep the filename and ask the other application to adapt...

[rogercreagh]

Just a quick followup. I see that rfc7986 (which I hadn't noticed before) actually adds a LABEL parameter. It was defined for the CONFERENCE property, but notes that since its intention is to provide a human readable label it could be usefully applied to other properties.
(see extract below)

So perhaps a feature request for jtxB would be in order to add the LABEL parameter to ATTACH properties. Need to think about what changes would be needed to the display and edit screens.

rfc7986 extract

[6.4](https://www.rfc-editor.org/rfc/rfc7986.html#section-6.4).  LABEL Property Parameter

   Parameter Name:  LABEL

   Purpose:  To provide a human-readable label.

   Format Definition:  This property parameter is defined by the
      following notation:

   labelparam = "LABEL" "=" param-value

   Description:  This property parameter MAY be specified on the
      "CONFERENCE" property.  It is anticipated that other extensions to
      iCalendar will reuse this property parameter on new properties
      that they define.  As a result, clients MUST expect to find this
      property parameter present on many different properties.  It
      provides a human-readable label that can be presented to calendar
      users to allow them to discriminate between properties that might
      be similar or provide additional information for properties that
      are not self-describing.  The "LANGUAGE" property parameter can be
      used to specify the language of the text in the parameter value
      (as per [Section 3.2.10 of [RFC5545]](https://www.rfc-editor.org/rfc/rfc5545#section-3.2.10)).

   Example:

   CONFERENCE;VALUE=URI;FEATURE=VIDEO;
    LABEL="Web video chat, access code=76543";
    :https://video-chat.example.com/;group-id=12

SIZE, FILENAME, and MANAGED-ID were all added in rfc8607 for managed attachments. I don't know if any servers are yet implementing managed attachments, but SIZE also would be a useful parameter for all attachments so the user (and the client app) had an idea of how enormous the attachment would be before doing anything with it.

[patrickunterwegs]

Hm, thanks, yes, actually I would favor the idea of following the managed attachments instead of adding another label for the filename.
But for implementing them, the bigger effort is on the server and maybe sync-side. DAVx5 friends are basically interested, but currently busy with push-functionality (push to sync) together with Nextcloud, so I'm afraid they won't be ready to tackle a new big thing in the next months...

[patrickunterwegs]

One more thing about the origin of the X-LABEL:
It's as I said, the parameter came from linux applications, I wrote a summary here:
#293 (comment)