Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adds Presentation Receiver status. #53

Merged
merged 4 commits into from
Sep 25, 2017
Merged

Adds Presentation Receiver status. #53

merged 4 commits into from
Sep 25, 2017

Conversation

mfoltzgoogle
Copy link
Contributor

Addresses Issue #11: Presentation API control protocol

Defines Presentation Reciever Status, the last message in the Presentation API control protocol.

Application Message:

  • Adds a Locale field.
  • Adds special handling for empty text messages.
  • Defines encoding of text messages.
  • Other corrections.

@tomoyukilabs
Copy link
Contributor

tomoyukilabs commented Sep 20, 2017 •
edited
Loading

Regarding a locale, it looks almost good to me! Locales of display's friendly name and presentation title are very helpful to display them properly.

On the other hand, I wonder if the MESSAGE_LOCALE field in Presentation Application Message would be useful or not. Unless any method or parameter to specify a locale of each message is not exposed to web applications, the field will eventually be set to the same string as specified in Presentation Initiation Request and will not vary until the presentation would be terminated.

By the way, I suppose that each locale field could have variable length. In most cases, a locale string is very short like en-US, zh-CN, zh-TW, ko, ja, etc.

@mfoltzgoogle
Copy link
Contributor Author

On the other hand, I wonder if the MESSAGE_LOCALE field in Presentation Application Message would be useful or not. Unless any method or parameter to specify a locale of each message is not exposed to web applications, the field will eventually be set to the same string as specified in Presentation Initiation Request and will not vary until the presentation would be terminated

Good point. I remember we discussed passing locale information with application messages, and deciding on leaving it up to the application, as it knows best which messages need a locale and what that locale is. In the future, we could add an API like send(<body>, <locale>) to allow applications to pass a locale with a string to capture this pattern.

For now, I'll remove MESSAGE_LOCALE since I don't think either end has a good way to fill it.

By the way, I suppose that each locale field could have variable length. In most cases, a locale string is very short like en-US, zh-CN, zh-TW, ko, ja, etc.

The BCP-47 spec doesn't seem to limit the length because of arbitrary variant strings that can be appended to the two letter codes. 64 characters captured all examples from the spec, but I didn't research this deeply. We could restrict to a subset of BCP-47 if we want to ensure shorter codes.

Maybe the i18n WG would have some advice for us on this.

@tomoyukilabs
Copy link
Contributor

In the future, we could add an API like send(, ) to allow applications to pass a locale with a string to capture this pattern.

I agree with that idea.

64 characters captured all examples from the spec, but I didn't research this deeply.

Okay. I just wanted to confirm the reason of 64 characters. Regarding the length, BCP-47 describes Length Considerations and indicates several examples and recommendations, e.g.:

  • historically most language tags have consisted of language and region subtags with a combined total length of up to six characters
  • RFC4646 recommended a minimum field size of 42 characters

Maybe the i18n WG would have some advice for us on this.

Absolutely.

@mfoltzgoogle
Copy link
Contributor Author

@tomoyukilabs

Okay. I just wanted to confirm the reason of 64 characters.

It was a best guess, and turns out to be consistent with the length guidelines in RFC4646.

In general, I'm using fixed length fields to constrain the message format when possible to simplify the code that constructs and parses these messages. If there's a need for language tags longer than 64 characters we can convert it to a variable length string (with a 16-bit length field).

I'll add a TODO with a followup issue to research this more and/or request input from the i18n group when ready.

@mfoltzgoogle mfoltzgoogle mentioned this pull request Sep 21, 2017
Closed
@mfoltzgoogle mfoltzgoogle merged commit ee8bec7 into gh-pages Sep 25, 2017
@mfoltzgoogle mfoltzgoogle deleted the issue-11-control-protocol-4 branch September 25, 2017 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@mfoltzgoogle @tomoyukilabs