Preserving the summary and subtitle tags

[Inrumpo]

As @eteubert pointed out over here, it seems like Apple has deprecated the itunes:subtitle and the itunes:summary tag.
Nevertheless, these tags can still be of value today (and are still in use), especially for UI purposes where space is limited.

Therefore I suggest preserving (and maybe re-defining) them as:

• <podcast:subtitle>
• <podcast:summary>

How this is to be implemented should be up for debate. The key questions are probably:

• Character limit?
• Plain text only?

[eteubert]

If memory serves, character limits were 255 for the subtitle and 4000 for the summary. Not sure if it needs to be a hard limit, but surely a recommendation.

Content should be plain text, but CDATA can be allowed, since it's just a different form of encoding special characters. But both podcasters and client developers should not write or render HTML in there.

[daveajones]

I’m good with putting those into the namespace. I’ll add it to the phase 8 plan.

[francosolerio]

I’m quite conflicted about this. From an app’s perspective—especially on mobile devices where screen space is limited—it’s challenging to decide which data to display in the UI. When fields like subtitle, summary, and description are all available, podcasters tend to use them in inconsistent ways. This makes it nearly impossible to choose a universally suitable option for display.

Apps often resort to algorithms with heuristics to determine which of the three fields offers the most meaningful description, but the results are always suboptimal. I believe this inconsistency is one of the reasons Apple decided to deprecate the summary and subtitle fields. RSS feeds impose no constraints, and having redundant fields introduces confusion and variability, which can be difficult—if not impossible—to handle effectively in code.

[Inrumpo]

If podcasters use different tags inconsistently, this would be a problem of clear definition of the tags. The podcaster needs to be told what each tag is for. We are free to (and should) do that ahead of time here.
Anyway, as I say below, I do see potential for confusion, especially with <description> and <summary>. But these two tags do something different than <subtitle>, so <subtitle> retains its own importance.

[jamescridland]

The OP states that these "are still in use". It would be helpful to understand how many feeds are, in fact, still using the itunes equivalent. I don't believe this to be the case for most podcasts out there.

[Marzal]

I would vote for "decluting" the feed/namespace, let them die. In line with Franco's commentary.

There is already <description> and <content:encoded> which I think is enough.

[Inrumpo]

@jamescridland
The best thing I found is this page stating ~36% for itunes:subtitle and ~78% for itunes:summary. Those percentages are said to be based on a sample of 233'569 podcasts.

@Marzal
It can be argued that <description> and <summary> perform similar tasks and that this can cause confusion. Clear definitions would be required here. I do agree that nobody needs two tags doing the same thing. Nevertheless, these tags all do something different than <subtitle>. Therefore <subtitle> would retain an independent value.