Proposal: <podcast:contact>

[theDanielJLewis]

What do you think of this proposal for a new podcast RSS tag as part of Podcasting 2.0?

(Nods to #10, #474, and #245, #769)

I suggest we pick up the conversation about adding properly formatted and more usable optional contact details to podcast feeds, using the tag <podcast:contact>. This would solve providing contact information, as well as booking information (#769) in a simple, readable, parsable way.

Similar to WHOIS/RDAP records for a domain, this tag can be repeated for multiple purposes.

Examples

<podcast:contact rel="feedback" href="mailto:feedback@podcast.com">Send us your feedback!</podcast:contact>
<podcast:contact rel="feedback" href="https://podcastfeedback.com/audacity">Send us your feedback!</podcast:contact>
<podcast:contact rel="feedback" href="tel:555-555-5555">Leave a voicemail!</podcast:contact>
<podcast:contact rel="sponsor" href="tel:555-555-5555">Sponsor the show</podcast:contact>
<podcast:contact rel="pitch-guest" href="https://podmatch.com/…">Be a guest!</podcast:contact>
<podcast:contact rel="invite-interview" href="https://podmatch.com/…">Interview the podcaster</podcast:contact>

This tag is simple in design, but still flexible.

Attributes

• rel (optional): like a normal <a> tag, this accepts one of several standard relationship indicators. These could include, but not be limited to, feedback, pitch-guest to pitch a guest to this podcast, invite-interview to invite this podcaster as a guest, sponsor, and maybe press(for press/media inquiries). If therel` attribute is omitted, the link is considered a general contact destination.
• href (required): this can link to anything that a normal <a> tag can link to: URLs, email addresses, telephone/SMS numbers, etc. This can be easily parsed by an app for possible design decisions. For example, displaying a mail icon for any mailto: links.

Value (optional)

The value allows the podcaster to define the label for the contact method, which can be displayed by an app. But the value can also be optional and the app can fall back to an icon or generic text like "Contact."

Display in podcast apps

Since the tag can have multiple instances, podcast apps could display a single "Contact" button that opens a tray to display the list of contact options, like this:

Alternatively, if the podcast app detects only a single <podcast:contact> tag, it could link directly to it and skip the tray.

How this addresses the "booking" need

I don't think we need yet another single-purpose tag for booking information. This proposed contact tag can handle that and address the other needs podcasters have for presenting contact information, especially if it's something other than an email address.

Publishing workflow

In a podcast-hosting provider or publishing tool, it would let podcasters add multiple contact rows, choosing the type (feedback, pitch-guest, sponsor, etc.), entering a URI with schema (the UI should detect if a URL, phone number, or email address is pasted and format appropriately), and an optional label.

It's that simple.

Plus, building on @Alex-Sanfilippo's booking idea (#769), the UI for populating booking information could actually be the same:

But instead of going into a <podcast:booking> tag, it would create and populate the correct booking options of a <podcast:contact> instance—accepting guests or being available as a guest.

Addressing the spam problem

Instead of existing RSS tags intended for sharing email addresses (and with no purpose or label), this tag can link to anything an <a> tag can link to, including email addresses, contact forms, SMS phone numbers, and more. Thus, the podcaster could link to anything but an email address.

Smarter features

Since this would follow the format of an <a> tag, that means smarter features can be added to the href attribute, including prepopulated emails or text messages, URL parameters, and such.

For example (courtesy of W3Docs):

<podcast:contact href="mailto:email@example.com?cc=secondemail@example.com,anotheremail@example.com&bcc=lastemail@example.com&subject=Podcast%20feedback=Some%20body%20text%20here">Send Email</podcast:contact>

Would send an email to email@example.com, CC secondemail@example.com and anotheremail@example.com, BCC lastemail@example.com, set the subject to Podcast feedback, and prepopulate the email body with Some body text here.

The way forward

Instead of multiple single-purpose tags all doing essentially the same thing, this tag unifies the ideas, adheres to common conventions, is simple to implement and support; and yet it is also future-friendly, extensible, and highly versatile.

[redimongo]

Cool idea, but could we not use the txt tag, its already supported by so many apps, and was designed to be versatile for situations like this.

[theDanielJLewis]

The problem with that is there's absolutely no structure to it. <podcast:txt> can hold anything. And by that logic, any new feature could just be crammed into the txt tag.

This provides more structure, common conventions, and would be easier for apps to parse.

[redimongo]

I get the logic.

[theDanielJLewis]

Updated my proposal to show how the booking UI from #769 could actually still be used to populate this tag.

[daveajones]

I like this a lot Daniel. Thank you for the UI examples. This is really helpful.

[theDanielJLewis]

I'd love discussion on the terminology for the standard rel values. The grammarian in me doesn't like how it's not a parallel list:

• feedback: noun
• sponsor: verb
• pitch-guest: verb
• invite-interview: verb
• press: noun

I think that list is the shortest and least ambiguous. If we switched them all to nouns, that creates some ambiguity or more potential for error (even though a UI should standardize these without the user's having to worry).

For example:

• feedback: noun
• sponsorship: noun
• guest-pitch: noun—we're good so far!
• interview-invitation: noun—this is where it breaks down. The correct grammar would be "invitation," but people these days use "invite" to mean "invitation."
• press: noun—I'm avoiding "media" here because that can mean too many different things within the podcasting context.

Even though I don't like having a non-parallel list, I think the mix of nouns and verbs is the simplest. But I'd love it all to be parallel if possible to do without creating ambiguity.

Any additional values that should be considered?

[matthewruzzi]

I think that it could be helpful to have a machine readable boolean value for whether or not the podcast accepts guests so that all podcasts that don't accept guests could easily be filtered out. This is one thing that the <podcast:contact> tag doesn't currently support. The <podcast:acceptsGuests> proposal did have this.

#769 (comment)

[theDanielJLewis]

That's actually not completely necessary. If the podcast uses <podcast:contact rel="pitch-guest" …>, then that means they accept guests. Thus, the presence of that tag is a "true" for whether they accept guests.

If they don't use it, then it's unknown (as most podcasts), or they don't accept guests.

[matthewruzzi]

If they don't include the tag they may or may not accept guests. It could be nice to have a way to specifically say that a podcast does not accept guests.

[theDanielJLewis]

That's a valid point. It also feel a bit weird to require podcasters to add a tag to indicate a false value. I'm not totally against the idea of <podcast:acceptsGuests> (#474), but just something to think about.

One way to do that with this tag could be:

<podcast:contact rel="pitch-guest">false</podcast:contact>

A similar approach could be taken to other forms of contact to explicitly indicate the podcast does not want that contact. For example:

<podcast:contact rel="sponsor">false</podcast:contact>

Omitting the href attribute would indicate a "false" value, but the "false" can be there to be explicit and readable.

[matthewruzzi]

I don't like the idea of the contents of the tag being used both as a boolean and a free text field.

[theDanielJLewis]

What would you suggest then?

[Alex-Sanfilippo]

This is brilliant... I'm in full support of it!

[J-J-Chiarella]

I'd love discussion on the terminology for the standard rel values. The grammarian in me doesn't like how it's not a parallel list:

* `feedback`: noun

* `sponsor`: verb

* `pitch-guest`: verb

* `invite-interview`: verb

* `press`: noun

I think that list is the shortest and least ambiguous. If we switched them all to nouns, that creates some ambiguity or more potential for error (even though a UI should standardize these without the user's having to worry).

For example:

* `feedback`: noun

* `sponsorship`: noun

* `guest-pitch`: noun—we're good so far!

* `interview-invitation`: noun—this is where it breaks down. The correct grammar would be "invitation," but people these days use "invite" to mean "invitation."

* `press`: noun—I'm avoiding "media" here because that can mean too many different things within the podcasting context.

Even though I don't like having a non-parallel list, I think the mix of nouns and verbs is the simplest. But I'd love it all to be parallel if possible to do without creating ambiguity.

Any additional values that should be considered?

The grammarian in me also likes the parallelism, but I think you may be hemming and hawing about it for good reason. A truly parallel setup is longer. I would also add something that you may have been thinking about too, which is the people who do not speak English. One, they may not appreciate the work that goes into parallelism, even if they know some English for computer science and programming. Two, the more letters, the greater the chances of error. If you do not know Korean, for example, and are just copying line after line of some documentation in Korean, it would be trivial to miss a typo such as 뭐을 or 무엇를 instead of 뭐를 or 무엇을. (It is like writing an napkin instead of a napkin.)

I know I am worrying over a tiny edge case and engaging in the bigotry of low expectations, but if it causes even one app developer in Bangladesh or Poland to screw up with podcast:interview-invitaton, it is not worth it.

The correct grammar would be "invitation," but people these days use "invite" to mean "invitation."

Oh dear, yes—plus, the usage of reveal instead of revelation. As much as it makes us sigh or groan, we may want to accept the noun usage of invite. For what it’s worth, I am still fighting the losing battle of using data as the plural of datum, so the data are. However, I flip on media as a singular thing nowadays or the plural of medium. If we analogize, we could assume that in computer lingo (and just look at Discord etc.) the word invite can be a noun.

To make things even shorter, how about podcast:invite and just note the word interview in documentation or in app displays but not the RSS feed?

---

In any case, for consistency, wasn’t camelCase baked into RSS from day one? managingEditor and so podcast:interviewInvite?

---

Thank you for the forward thinking with this. I do wonder if the absence of such a tag is the explanation for the widespread persistence of the officially deprecated itunes:email (nested within itunes:owner). People want some contact link or email address in there?