list of displays: should it address display name, language, etc.?

[aphillips]

The I18N working group is doing some housekeeping and found that we didn't forward the below issue. Apologies for being late with this. Note that this may already be addressed by other threads about language.

http://w3c.github.io/presentation-api/

Section: The list of available presentation displays

This section contains the directive that:

The user agent MUST keep a list of available presentation displays. This current list of presentation displays may be used for starting new presentations, and is populated based on an implementation specific discovery mechanism. It is set to the most recent result of the algorithm to monitor the list of available presentation displays.

This list appears to be identified using URLs for each presentation display. The specification is silent about such issues as display name, sorting order, etc. These issues may affect actual implementation, even though this API doesn't really address the issue. Should it?

[aphillips]

(could you please add the label "i18n" to this issue?)

[tidoust]

I believe that the specification is silent on purpose here, to let implementers adjust their chrome and user experience as they see fit. For instance, a controlling user agent could choose to list displays that the user previously interacted with first, or sort displays it finds by proximity, or filter out displays that it deems not trustworthy, etc. In other words, the expectation is not that two controlling user agents will display the same list of available displays, and that they will appear in the same order.

The amount of information that the controlling user agent has on the available displays also depends on the discovery mechanism used under the hoods, which is out of scope of this specification. The user agent may be able to learn about all sorts of capabilities that the display supports, including locale support. Or it may not know much on top of the display name.

The spec could perhaps include some guidance about possible localization issues. I'm not clear how the display name could affect the actual implementation though. Do you have examples of issues that could arise, @aphillips ? For instance, is the problem that the user agent may not be able to render the name if the display name uses characters that are not supported by the user agent?

Side note: the list of displays is not identified using URLs. Each presentation display is associated with a list of URLs that it is compatible with, but it is not an identifier for the display. How the display gets identified is up to the implementation. It will probably be based on its IP address (possibly its MAC address on the LAN), or on some identifier exposed by the display itself.

[aphillips]

@tidoust There are a number of issues that could arise, but these would depend on implementation details. As long as the spec doesn't make normative statements about the presentation of the list, though, I'm not sure you need to enumerate what all of the potential problems are. Which is why the issue basically asks "should there be something here?". I'm not sure that there should be.

The main issues for presentation of individual display names would be language and direction metadata. These ought to be provided so that font selection/fallback works appropriately (language) and so that mixed direction display names are correctly formatted (direction). However, if I recall correctly, we've dealt with those in separate issues. Lack of local fonts for displaying characters is a problem that can arise but not something your spec can really address either: it is just a general problem for user agents.

Of the other issues that occur to me, sorting of the list is probably the main I18N issue that implementers might trip over. Unicode code point order is not a particularly user-friendly sorting, but proper collation involve the user's locale expectations. But your spec is silent about how the list is presented. I'd suggest leaving well enough alone and would suggest you close the issue.

[tidoust]

Thanks for the feedback @aphillips.

We've dealt with language issues for messages exchanged between the controlling side and the receiving side over the communication channel (the spec now includes guidance for developers and a related example), as well as for passing the locale from the controlling side to the receiving side (now a SHOULD in the spec), but not really for the list of available displays.

I don't see how the spec could mandate anything on the topic, but it could perhaps point out that receiving user agents are encouraged to advertise the language and direction metadata along with their display name. I do not know if that it is actually doable with usual advertising protocols on the LAN though.

[tomoyukilabs]

@tidoust

I do not know if that it is actually doable with usual advertising protocols on the LAN though.

As far as I investigated, it might depend on advertising protocols. In SSDP, parameters such as <friendlyName>, etc. indicated in UPnP Device Description can be localized by Accept-Language and Content-Language HTTP headers (see Section 2.3 in UPnP Device Architecture). However, I am not sure whether there is any display applying such localization or not. On the other hand, mDNS does not seem to provide any record to indicate the language of display's name.

[markafoltz]

For background, there are a couple of reasonable ways a friendly display name can be passed through mDNS:

1. Via the instance name in the DNS SRV record advertised by a service instance. The spec [1] says that this must be up to 63 Net-Unicode characters, but doesn't have any place to pass locale information that might be used to customize the display of the name.
2. Via a DNS-TXT record [2]. The TXT record is a list of key=value strings up to 255 bytes in length. However it is completely up to the implementation how to populate this record. An implementation could use one string to pass the name (as unicode) and another string to pass the locale.

What I propose is implementation guidance along the lines of @tidoust:

• That the receiving user agent advertise the locale (language, direction) to be used to interpret the display name.
• That the controlling user agent take that into consideration when rendering that name, when available.

[1] https://tools.ietf.org/html/rfc6763#section-4.1
[2] https://tools.ietf.org/html/rfc6763#section-6