MimiContent should have optional Subject text field

[RonPeters]

Most of the time we do not think of subject lines for chat-style messaging, but there are many instances where subject lines are currently allowed (both inline and in threaded chats). For instance, iMessage, Microsoft Teams, and even MMS all allow subject lines. I believe it should be added as an optional field in MimiContent for feature parity.

[rohan-wire]

Hi Ron, I am moderately skeptical of, but not inherently opposed to, a Subject field for MIMI content.

I have a few questions. The first is what the semantics would be of the field. Is this the subject of the conversation/room, or the subject of the specific message? If it is the subject of the room, it probably doesn't belong in this content format, but more likely in the room state.

Would it ever be used to organize threads of messages? How would its use relate to the topicId field?

Next, do we have any information on how common is it that someone actually set a per-message Subject in iMessage or Teams? In the case of MMS, most clients don't have a UI that allows someone to set a per-message Subject, so I don't find the MMS argument especially compelling for inclusion in MIMI content.

[RonPeters]

Hi Rohan,

Thank you for considering. I believe it is a bit of an outlier, but corresponds to some useful real-world contexts.

For instance, in Teams, a post in a team discussion (as opposed to a direct chat) can have an optional subject line. Replies to that post become threaded and is very useful for organizing threads. I believe this would correspond to setting a subject on the first message with a particular topicId.

Regarding mobile clients, both iMessage and Google Messages have simple ways of enabling subject lines in the UI. Although I expect the actual usage is likely low, but it is there.

-Ron

---

From: rohan-wire @.> Sent: Wednesday, February 7, 2024 2:11 PM To: ietf-wg-mimi/draft-ietf-mimi-content @.> Cc: Ron Peters @.>; Author @.> Subject: Re: [ietf-wg-mimi/draft-ietf-mimi-content] MimiContent should have optional Subject text field (Issue #7)

Hi Ron, I am moderately skeptical of, but not inherently opposed to, a Subject field for MIMI content.

I have a few questions. The first is what the semantics would be of the field. Is this the subject of the conversation/room, or the subject of the specific message? If it is the subject of the room, it probably doesn't belong in this content format, but more likely in the room state.

Would it ever be used to organize threads of messages? How would its use relate to the topicId field?

Next, do we have any information on how common is it that someone actually set a per-message Subject in iMessage or Teams? In the case of MMS, most clients don't have a UI that allows someone to set a per-message Subject, so I don't find the MMS argument especially compelling for inclusion in MIMI content.

—

Reply to this email directly, view it on GitHubhttps://github.com/ietf-wg-mimi/draft-ietf-mimi-content/issues/7#issuecomment-1933022002, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ASF44GP37KBRIPHYAHVAHFDYSP3ZJAVCNFSM6AAAAABCNUH5SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZTGAZDEMBQGI.

You are receiving this because you authored the thread.

[rohan-wire]

Hi, I think the Teams use case you described can be implemented with the topicId.

I think the iMessage/MMS use case is to set the subject for the "conversation" and not per message, but I could be wrong on that. Thanks, -rohan

On Wed, Feb 7, 2024, 17:44 Ron Peters @.***> wrote:

Hi Rohan,

Thank you for considering. I believe it is a bit of an outlier, but corresponds to some useful real-world contexts.

For instance, in Teams, a post in a team discussion (as opposed to a direct chat) can have an optional subject line. Replies to that post become threaded and is very useful for organizing threads. I believe this would correspond to setting a subject on the first message with a particular topicId.

Regarding mobile clients, both iMessage and Google Messages have simple ways of enabling subject lines in the UI. Although I expect the actual usage is likely low, but it is there.

-Ron

---

From: rohan-wire @.> Sent: Wednesday, February 7, 2024 2:11 PM To: ietf-wg-mimi/draft-ietf-mimi-content @.> Cc: Ron Peters @.>; Author @.> Subject: Re: [ietf-wg-mimi/draft-ietf-mimi-content] MimiContent should have optional Subject text field (Issue #7)

Hi Ron, I am moderately skeptical of, but not inherently opposed to, a Subject field for MIMI content.

I have a few questions. The first is what the semantics would be of the field. Is this the subject of the conversation/room, or the subject of the specific message? If it is the subject of the room, it probably doesn't belong in this content format, but more likely in the room state.

Would it ever be used to organize threads of messages? How would its use relate to the topicId field?

Next, do we have any information on how common is it that someone actually set a per-message Subject in iMessage or Teams? In the case of MMS, most clients don't have a UI that allows someone to set a per-message Subject, so I don't find the MMS argument especially compelling for inclusion in MIMI content.

—

Reply to this email directly, view it on GitHub< https://github.com/ietf-wg-mimi/draft-ietf-mimi-content/issues/7#issuecomment-1933022002>, or unsubscribe< https://github.com/notifications/unsubscribe-auth/ASF44GP37KBRIPHYAHVAHFDYSP3ZJAVCNFSM6AAAAABCNUH5SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZTGAZDEMBQGI>.

You are receiving this because you authored the thread.

— Reply to this email directly, view it on GitHub https://github.com/ietf-wg-mimi/draft-ietf-mimi-content/issues/7#issuecomment-1933234033, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVXAIJ6ON4JFWTHANHPTJ4TYSQUWRAVCNFSM6AAAAABCNUH5SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZTGIZTIMBTGM . You are receiving this because you commented.Message ID: @.***>

[RonPeters]

Hi Rohan,

In the Teams case, the topicId is just an identifier (like a "thread ID"), not a human-readable string, correct? So I don't see how that fulfils the object of having a subject line for the thread.

Regarding the MMS case, both iMessage and Google Messages allow setting the subject for an individual message. The Google Messages UX is deficient, in my opinion, because the menu item seems to be associated with the conversation, but the actual action is to enable the subject line for the next message you send.

Regards, -Ron

[RonPeters]

I just watched the IETF 119 MIMI meeting. I only brought up Subject as a field because perhaps I did not understand the extensibility points in MIMI. I would much rather have Subject be some kind of extension to the message, but I'm not sure where that would fall in the spec. Would it be a "SubjectPart"? In any case, I am all for using extensibility to address this.

Regards, Ron

[RonPeters]

Thinking some more, I guess it could be a Disposition type

[RonPeters]

Or, I guess it could be a SinglePart with embedded RDF:

contentType: application/json+ld
content:
{
    "@context": "https://schema.org",
    "@type": "Message",
    "name": "Example Subject"
}

Would this be an appropriate direction? I definitely don't want to burden the spec with edge cases. I'm just looking for an acceptable way to carry the data in the payload.

[rohanmahy]

Hi Ron, If you want this to be the subject of a message, you couldn't use SinglePart. You could have a two parts bound together, but I think for an object that describes the message, I think having a clear extensibility scheme will be easier with a concrete syntax will be easier. I should have concrete TLS Presentation Language and CBOR syntaxes within a few weeks. Thanks, -rohan

On Sat, Mar 23, 2024, 04:40 Ron Peters @.***> wrote:

Or, I guess it could be a SinglePart with embedded RDF:

contentType: application/json+ld content: { @.": "https://schema.org", @.": "Message", "about": { @.***": "Thing", "name": "Example Subject" } }

Would this be an appropriate direction? I definitely don't want to burden the spec with edge cases. I'm just looking for an acceptable way to carry the data in the payload.

— Reply to this email directly, view it on GitHub https://github.com/ietf-wg-mimi/draft-ietf-mimi-content/issues/7#issuecomment-2015699107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADSQPSMWKFBRMWZO7LFYU3YZR3LBAVCNFSM6AAAAABCNUH5SGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJVGY4TSMJQG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[RonPeters]

Hi Rohan,

Agreed that clear extensibility is the best solution. I thought perhaps I had missed something in the existing spec, so I appreciate your consideration and I look forward to seeing it in future revisions.

Regards, -Ron