Commercial software support is not free. Contracting out for professional services or diverting internal developers to fix issues with open source software are also not free.
> yes I know there was one iPad that could do USB 3 with one special dongle - and it couldn’t even do video out well with the dongle. The video adapter had hardware to decompress a compressed video stream and convert it.
Those are two separate things.
These iPad models had USB 3.0 over lightning. Lighting however was designed to solve the 30 pin connector "alt mode" problem. USB-C recreated the "alt mode" problem.
In the original 30-pin iPod, iPhone and iPad days, you had multiple video out adapters to support RCA, VGA, composite, and so on. These were also _different_ with the different i-device models - the adapters were not backward compatible, so when they came out with a new higher-resolution model of dongle, it wouldn't work on older devices. Conversely, the complexity of supporting various hardware mappings onto the 30 pin connector meant that older dongles could get deprecated from new devices.
There weren't a lot of people who invested in video output for their I-devices, but for those who did this was a very frustrating issue.
So for lightning, they went to serial protocols. So rather than negotiate a hardware mode where certain pins acted like HDMI pins in a pass-through mode, they streamed a H.264 video to the dongle - the dongle then rendered it and used its own HDMI output support.
Since this was software negotiation, a newer dongle could support new video formats and higher resolutions while still supporting older devices. There were also examples of improvements pushed to more complicated dongles like the HDMI adapter via software updates. But fundamentally, the complexity of supporting a broad hardware accessory ecosystem wasn't pushed into the physical port - it could evolve over time via more complex software rather than via increasingly complicated hardware in every phone.
With USB-C we are back to guessing whether the connector is expecting the phone to support HDMI alt mode, DisplayPort alt mode, MHL alt mode, or to output a proprietary system like DisplayLink data.
USB 3.0 (which is what these iPads supported) never had these alt modes. It was USB-C which became a connector for (optionally) supporting a lot of other, non-USB protocols. The lack of USB-C support is why these iPads only supported video out with the lightning to HDMI adapter.
USB-C is decent, but it suffers quite a bit from there not being strong certification. This is partly why Thunderbolt 5 has shifted to becoming a compatibility- and capability- oriented certification mark. You know for example that thunderbolt 5 video will always work, because the cables have all the data pins and the devices are going to support DisplayPort alt mode.
It does not preclude other post-quantum algorithms from being described for use with TLS 1.3. It also does not preclude hybrid approaches from being used with TLS 1.3.
It is however a document scoped so it cannot be expanded to include either of those things. Work to define interoperable use of other algorithms, including hybrid algorithms, would be in other documents.
There is no MTI (mandatory-to-implement) once these are documented from the IETF directly, but there could be market and regulatory pressures.
My suspicion is that this is bleed-out from a larger (and uglier) fight in the sister organization, the IRTF. There, the crypto forum research group (CFRG) has been having discussions on KEMs which have gotten significantly more heated.
A person with concern that there may be weaknesses in a post quantum technique may want a hybrid option to provide additional security. They may then be concerned that standardization of non-hybrid options would discourage hybrid usage, where hybrid is not yet standardized and would likely be standardized later (or not at all).
The pressure now with post quantum is to create key negotiation algorithms are not vulnerable to theoretical post quantum computer attack. This is because of the risk of potentially valuable encrypted traffic being logged now in the hopes that it could later be targeted by a post-quantum computer.
Non-negotiated encrypted (e.g. just using a static AES key) is already safe, and signature algorithms can be updated much closer to viable attacks to protect transactional data.
> It is however a document scoped so it cannot be expanded to include either of those things. Work to define interoperable use of other algorithms, including hybrid algorithms, would be in other documents.
You may misunderstand how the IETF works. Participation is open. This means that it is possible that people who want the work to fail for their own reasons rather than technical merit can join and attempt to sabotage work.
So consensus by your definition is rarely possible given the structure of the organization itself.
This is why there are rough consensus rules, and why there are processes to proceed with dissent. That is also why you have the ability to temporarily ban people, as you would have with pretty much any well-run open forum.
It is also important to note that the goal of IETF is also to create interoperable protocol standards. That means the work in question is a document describing how to apply ML-KEM to TLS in an interoperable way. It is not a discussion of whether ML-KEM is a potentially risky algorithm.
DJB regularly acts like someone who is attempting to sabotage work. It is clear here that they _are_ attempting to prevent a description of how to use ML-KEM with TLS 1.3 from being published. They regularly resort to personal attacks when they don't get their way, and make arguments that are non-technical in nature (e.g. it is NSA sabotage, and chairs are corrupt agents). And this behavior is self-documented in their blog series.
DJB's behavior is why there are rules for how to address dissent. Unfortunately, after decades DJB still does not seem to realize how self-sabotaging this behavior is.
> the work in question is a document describing how to apply ML-KEM to TLS in an interoperable way. It is not a discussion of whether ML-KEM is a potentially risky algorithm.
In my experience, the average person treats a standard as an acceptable way of doing things. If ML-KEM is a bad thing to do in general, then there should not be a standard for it (because of the aforementioned treatment by the average person).
> It is clear here that they _are_ attempting to prevent a description of how to use ML-KEM with TLS 1.3 from being published.
It's unclear why trying to prevent a bad practice from being standardized is a bad thing. But wait, how do we know whether it's a good or bad practice? Well, we can examine the response to the concerns DJB raised: Whether the responses satisfactorily addressed the concerns, and whether the responses followed the rules and procedures for resolving each of those concerns.
> They regularly resort to personal attacks when they don't get their way
This is certainly unfortunate, but 6 other parties upheld the concerns. DJB is allowed to be a jerk, even allowed to be banned for abusive behavior IMO, however the concerns he initially raised must nonetheless be satisfactorily addressed, even with him banned. Banning somebody is sometimes necessary, but is not an acceptable means of suppressing valid concerns, especially when those concerns are also held by others who are not banned.
> DJB's behavior is why there are rules for how to address dissent.
The issue here seems to be that the bureaucracy might not be following those rules.
No, because in this hypothetical you have some authority to discipline that someone. That's what's going on here: DJB is calling out people in the IETF leadership -- people who can dole out posting privileges bans and what not. DJB is most likely going to skirt the line and not go over it, which is what's really tricky here, but the IESG could say they've had enough and discipline him. The trouble is that the underlying controversy does need to be addressed, so the IESG doesn't have completely free hand -- they can end up with a PR problem on their hands.
> So all someone who is being abusive has to do to force me to be stand there and be abused by them is to call me corrupt?
In this example, rectifying concerns is your job, so yes, you have to do it, even if 1 of the 7 parties who hold the concern is a jerk*. Officials can't dispense with rules and procedure just because their feelings are hurt.
If you are actually corrupt**, it isn't abuse. If you aren't, it still isn't abuse. Even if it is abuse, and you deal with it sanctions, you must still rectify the substance of the concerns upheld by 6 other parties.
* 1/7 would be a pretty desirable jerk/total ratio, in my experience
** (and officially behaving differently based on personal animus makes one so)
A lot of zigbee infrastructure also expect an internet connection.
These border routers also double as admins, and people want their smart home stuff to be available while they are outside their home network.
Thread devices can mandate internet connectivity the same way Wifi devices can.
Matter defines profiles and does certification that says your light bulbs cannot require an internet connection. The admin your water leak detector connects into can (and arguably should) alert you even when you are away from home, but the leak detector _itself_ cannot do that and be certified.
> A lot of zigbee infrastructure also expect an internet connection.
Like what. I have several hundred zigbee devices of almost all category you can think of, and I have never come across such a requirement. I don't understand how that would even work.
Yes, USB extenders are not spec-legal (because the device isn't built expecting to be extended).
But you can have an extension cord which accepts USB on one end but doesn't accept USB on the other.
So the keyboard has a superset connector so that it can go in regular USB and notched USB, because it is verified to work right when using the extension cord.
This design also means you can't plug one extension cord into another to get an even longer distance (which the keyboard wouldn't expect). Pretty clever solution.
The lowest level of the three is not a useful number. The case serves as a battery pack to recharge the headphones (something I did earlier today while on an international flight).
The reality is the sort of compatibility being talked about is a new feature with design choices, not just unwired functionality.
I'd rather them work on features to report charging time or expected playback time on iOS, or write their own app for Android, than try to arbitrarily increase their bluetooth profile compatibility checklist.
You said when I asked which should get reported “Whatever is reported to iPhones. It's not an excuse to block non Apple devices from reading battery level”
Exactly how is Apple going to send information to none Apple devices using the BT protocol in a method that they can understand?
reply