[SSDP] Ensure that advertised friendly names are i18n capable

[markafoltz]

From https://github.com/webscreens/openscreenprotocol/pull/20/files#r108024631

---

mfoltzgoogle 3 days ago Collaborator How is FRIENDLY-NAME encoded? @louaybassbouss louaybassbouss 2 days ago Collaborator it is just a clear-text string field like the other SSDP headers. @mfoltzgoogle mfoltzgoogle 9 minutes ago Collaborator Since it's displayed to humans, it should be able to represent Unicode code points. We can look at the SSDP spec to see what is supported by default.

[louaybassbouss]

according to UPnP Device Architecture v1.1, section 1.1 SSDP message format:

All SSDP messages MUST be formatted according to RFC 2616 section 4.1 “generic message”. SSDP messages MUST have a startline and a list of message header fields. SSDP messages SHOULD NOT have a message body. If a SSDP message is received with a message body, the message body MAY be ignored.

[markafoltz]

Does uPnP mandate a transfer-encoding for the message?

[tomoyukilabs]

@mfoltzgoogle Though UPnP Device Architecture mentions Transfer-Encoding (as an optional feature for HTTP/1.1), a Transfer-Encoding does not appear in Section 1. Discovery (i.e. SSDP).

[markafoltz]

I did some tracking of this. The short answer for SSDP is "not simply."

SSDP adopts the RFC 2616 message format from HTTP 1.0 [1] which technically allows ISO-8859-1 in header values (although only ASCII is guaranteed to work across implementations.) Non-ASCII values (i.e., UTF-8) should use MIME encoding [2], basically quoted-printable or base64.

[1] https://www.ietf.org/rfc/rfc2616 [2] https://www.ietf.org/rfc/rfc2047

base64 is simpler and universally supported. So if we want to include the friendly name in the SSDP response, it should be base64 encoded.

[markafoltz]

Closing as we are not using SSDP.