[SSDP] Ensure that advertised friendly names are i18n capable about openscreenprotocol HOT 5 CLOSED

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.

from openscreenprotocol.

Does uPnP mandate a transfer-encoding for the message?

from openscreenprotocol.

@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).

from openscreenprotocol.

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.

from openscreenprotocol.

Closing as we are not using SSDP.

from openscreenprotocol.