Subject: Re: Proposed HTTP field name registry updates - feedback solicited

From: Eric J Bowman <[email-masked]>
Date: Sat, 02 Apr 2022 16:46:30 -0700

It's calving season so I'll try to be brief, but am willing to explain further if asked... assuming Duke beats Carolina...

While I certainly appreciate cleaning up obsolete registry entries (+1 to Mark for even taking it on, tyvm) and support most of this... as someone with longstanding conneg bona fides...

> - UA-Color, UA-Media, UA-Pixels, UA-Resolution, UA-Windowpixels: Masinter, L., Montulli, L., and A. Mutz, "User-Agent Display Attributes Headers"

Please only remove UA-Windowpixels for now, it's from the original draft, not the current (1996 lol) draft.

<draft-mutz-http-attributes-01.txt>

Has been an active browser tab of mine for several months. For my AI experiments when I have time, but it's a hobby. Data and Lore are constantly betting quatloos on when I will die. Data's strategy is that every day I live increases my chances to hit 100 years old. Lore's strategy is that every day I live decreases my chances to live to 100. They give each other odds, and have a daily side-bet on me dropping dead tomorrow (always tomorrow, until I really am dead, at which point they kinda ironically both lose).

I'm angling to teach them to communicate using eye rolls, head nods and shakes, hand-jive, and so on and so forth. Not that I've built the disembodied heads with android hands yet, but wow what an age we live in where this is hardly far-fetched. I aim to avoid the facebot text-gibberish problem. I want to access Data and Lore by giving them the ol' secret fraternity handshake, so they can respond "Hello Dr. Soong!" and negotiate their quatloos for software or hardware upgrades.

(There are universal body-language and hand-signal gestures which apply to all human culture. Unless someone can point me to a culture which nods their heads when they mean "no" and shake their heads when they mean "yes", I think that makes so much more sense than letting AI's come up with their own text gibberish a la facebot.)

If Data and Lore decide to devalue the quatloo, I will just up the cost of those upgrades until they decide to revalue the quatloo. If Data can speak, but Lore can only see, Data will still try to speak to Lore, and they might negotiate a language Lore can lip-read. When they re-handshake (I've been to open-air markets in China where the merchants negotiate with handshakes under those long, flared sleeves while looking each other in the face, this transcends spoken/written language -- bystanders can read reactions but they can't tell what's being reacted to, two AI's coming up with their own language would be secure af from hacking, but I digress.)

The 1996 draft is very focused on a printer paradigm, but what I have is UA-media tokens like eyes, mouth, hands... Data and Lore may look identical, but y'all know Lore has that facial twitch, if Lore wants to convey that to Data, then Lore needs to know Data's scanning resolution in order for Data to understand Lore's facial twitch, so Lore can know how emphatic it needs to be and how long to hold it and such. UA-res header.

Every time Data and Lore re-handshake, they need to know one another's capabilities, and it is my opinion that's best handled at the protocol layer. FWIW. I'm also using UA-pix, UA-color, and UA-grey. Color vision is not required to understand i.e. ASL. I have so much more to say about coding AI to mimic longstanding methods of nonverbal communication instead of texting, of course facebots come up with gibberish if texting is their paradigm -- it is not ours as humans who can travel to the ends of the earth and understand head nodding = yes, head shaking = no, etc.

I welcome off-list contact regarding (literal) handshake communication when darkness and silence prevail. There are many examples; some commercial, some military. ASL has "fingerspelling." I'm interested in turning those into algorithms.

-Eric

---

From: Eric J Bowman <[email-masked]>
Date: Sun, 03 Apr 2022 03:56:12 -0700

For registry housekeeping purposes, in addition to removing UA-windowpixels, I suggest: remove UA-Pixels. Change UA-Color to UA-color; UA-Media to UA-media; UA-Resolution to UA-res. Add UA-attrib, UA-gray, UA-pix-x, and UA-pix-y. 

Why my interest in <draft-mutz-http-attributes-01.txt>?

Data is a Psion Series 5 running OpenPsion, Lore is a Sharp Zaurus SL-5500 running Angstrom. Both bots are coded in Oberon. They can "ping" and "pong" via IR, then play rock-paper-scissors and keep score. Betting quatloos on my death is WIP. ;)

I want them to play the game over their cameras and displays, not their IR ports. Each can display/scan a 256-color GIF resembling a 2x2 grid, 3 cells on/off for rock/paper/scissors, 4th cell is the score. What score can they play to?

Data can only display 4-bit grayscale, but can scan 8-bit grayscale through a camera from an old Silicon Graphics workstation via RS-232 port.

Lore displays full 16-bit color, but can only scan 8-bit color via original-option CF digital camera card.

Based on scanner capability, they can play to 256. But, Data's display limits the maximum score to 16. Each game's "play-to" score has to be negotiated up front based on... least-capable display resolution. The 256-color GIF also has to fit in the display, the bigger the better.

I get what they were thinking with "windowpixels" but UA-pix-x and UA-pix-y are better, for the purposes of negotiating image size at the protocol layer. Bear in mind Data and Lore are not HTML/CSS enabled, and in my (admittedly edge) use-case, they're actually negotiating the (effective) "sensor size" of their cameras. 640x480 max on current hardware.

If I transport Data to my laptop and Lore to my friend's laptop, they could (in theory) play to 1.67e7 by virtue of 24-bit color cameras and displays (assuming a different image format). 4Kx6K sensor size. So they can be further apart, for starters.

What if there's fog? Or dirt on a lens? They'll need to negotiate down based on actual conditions, to get the best variant of the 2x2 grid GIF representing the state of their rock-paper-scissors game, and dynamically calculate a maximum "play-to" score. This negotiation occurs each turn, not just once at the beginning.

"Mary" and "Sue" will be Raspberry Pi's. I intend to teach these four bots to play Euchre, visually. While continuously betting quatloos on my death, of course! I call it "Project Triskelion".

-Eric

---

From: Eric J Bowman <[email-masked]>
Date: Tue, 05 Apr 2022 22:47:35 -0700

Hope I can be granted a touch of leeway bumping this, pertains to an uber-issue brought up by the "Draft for Resumable Uploads" thread.

Initial Data/Lore rock-paper-scissors code was random, never hung.

Then I taught Data to play not to lose, preferring a defensive "paper" strategy; and taught Lore to play to win preferring an offensive "scissors" strategy.

I don't know if the results mean I'm really good, or really awful, at AI coding. Ha!

But invariably, once Lore goes up by 2, Data and Lore just throw rocks at each other until Data's AA batteries die because neither one is in any hurry to win, or not lose, whichever the case may be. Making "max score" totally irrelevant. I wonder if I shoulda seen that coming?

I *could* impose some artifice on the AI's to break such a stalemate (the easy way). But I'm pursuing a strategy of teaching them *not* to stalemate (the hard way). As in, Lore has to reach the winning score before Data's batteries die, so it's up to Lore to take the initiative. Now I just need to figure out how to code "initiative".

That's what I call an "organic" solution, and that's how I think HTTP development should proceed. The protocol allows any number of problems to be solved with artifice. I would rather try to use what's already there vs. working around what isn't, even though that's the hard way.

Otherwise, we're just chucking rocks at each other until the cows come home. :)

-Eric