Virtual Power Plants and the California Grid

The California Independent System Operator (CAISO) has published a report regarding electricity generation in the summer of 2025, which includes data through the end of September 2025. They provide a nifty interactive chart at that link, and the underlying data is easy to find in the source of the web page. I've included the data for July and September at the bottom of this post, as we're going to dive into those details in a moment.

Below is the graph of the sources of energy on the California electrical grid in September of 2025, the period ending about two weeks ago at the time of this writing. Importantly, the Solar resources shown are only utility connected solar arrays. Rooftop solar is behind the meter, reducing demand for electricity rather than adding to the supply measured here. There is approximately another 19 Gigawatts of solar capacity installed behind the meter.

---

This is the same data, shown as a percentage of the total. Because total electricity consumption varies throughout the day, the contribution of baseload sources like Methane-fired generators varies as a percentage of the total even though their output is constant.

A few observations:

• The contribution of wind power is smaller than I expected. I may get a skewed view of the prevalence of wind generation in California as I pass through the Altamont Pass wind farm regularly, but I expected wind to be a larger percentage.
• It is too small to be visible in the graph, but Solar power never actually drops to zero. It continues to supply about 4 Megawatts all night. I believe this might be Ivanpah, a solar thermal generation plant in the desert, which continues generating power from stored heat even after the sun has set.

---

I tried to incorporate behind-the-meter solar into a similar graph, below. This is a crude estimate:

• In 2024, 19 Gigawatts of rooftop solar was installed versus 21 GWatts of utility-scale. I made the assumption that the production from rooftop solar would be approximately 19/21 of the utility number.
• Prior studies show that rooftop solar is not installed in ideal locations nor properly angled toward the sun, I made the additional assumption that it would be 80% as productive as utility solar.

The result hews considerably closer to the 67% renewable result announced by the state last year.

---

Virtual Power Plants

I have combined the categories which CAISO reported separately as Batteries and Demand Response, because until 4/2024 Virtual Power Plants formed via aggregation of residential batteries like Powerwalls were contracted as Demand Response. Only utility-scale battery installations like Megapacks were accounted for as Batteries. Splitting into two categories obscures and substantially minimizes the true contribution of battery power to the grid.

We participate in a Virtual Power Plant in northern California, allocating about half of the 27 KWh of capacity installed at the house. For a number of days this summer in the late afternoon and early evening, the house supplied about 6 kilowatts of power back to the grid. It is quite smooth, we don't even notice unless we look at the app to see what it is doing.

---

Raw data from the CAISO report web page.

"September": [
  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1392.000662, 1319.840318,            // Demand Response
   1239.827827, 1177.653666, 1023.942241, 287.33, 0, 0],                                // Demand Response

  [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2264.012689, 6312.981683,            // Battery Storage
   10219.53932, 9740.80126, 7382.450552, 5789.963039, 2869.891625, 0],                  // Battery Storage

  [11665, 11665, 11665, 11665, 11665, 11665, 11665, 11665, 11665, 11665, 11665,         // Imports
   11665, 11665, 11665, 11665, 11665, 5500, 5500, 5500, 5500, 5500, 5500, 5500,         // Imports
   11665],                                                                              // Imports

  [742.4458, 725.114696, 719.58188, 591.859728, 356.992952, 328.293048, 330.9584,       // Wind
   323.6145657, 277.992424, 205.762648, 221.590544, 199.863504, 216.38616,              // Wind
   311.644072, 316.5584821, 324.313968, 396.1921449, 535.622064, 785.470392,            // Wind
   905.120696, 1081.627632, 1164.064064, 1096.58392, 1058.725816],                      // Wind

  [3.7224, 3.7224, 3.95928, 4.43304, 5.02524, 7.1064, 155.30868, 3417.63696,            // Solar
   8622.78732, 11304.55656, 12390.19452, 12923.98668, 13035.8448, 12592.86717,          // Solar
   12166.76592, 11529.86232, 8779.161639, 5405.92308, 1148.5296, 12.79152,              // Solar
   5.34672, 4.01004, 3.8916, 3.84084],                                                  // Solar

  [1755.632861, 1755.632861, 1755.632861, 1755.632861, 1755.632861, 1755.632861,        // Other renewables
   1755.632861, 1755.632861, 1755.632861, 1755.632861, 1755.632861, 1755.632861,        // Other renewables
   1755.632861, 1755.632861, 1755.632861, 1755.632861, 1755.632861, 1755.632861,        // Other renewables
   1755.632861, 1755.632861, 1755.632861, 1755.632861, 1755.632861, 1755.632861],       // Other renewables

  [1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682,        // Other
   1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682, 1682],                   // Other

  [7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014,        // Hydro
   7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014, 7014],                   // Hydro

  [2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280,        // Nuclear
   2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280, 2280],                   // Nuclear

  [26188, 26188, 26188, 26188, 26188, 26188, 26188, 26188, 26188, 26188, 26188,         // Methane
   26188, 26188, 26188, 26188, 26188, 26188, 26188, 26188, 26188, 26188, 26188,         // Methane
   26188, 26188],                                                                       // Methane

  ...
]

Germany Photos Then and Now

In our collection of family photos we have a number of sets taken in Germany over the decades:

• in the early 1950s by my spouse's grandparents
• in the late 1960s by my father while stationed in Germany
• in 1995 by my spouse
• in summer 2024 on our first family trip to Germany
• in summer 2025 on our second family trip to Germany

In our trips of the last several summers we've made an effort to take photos of places our parents visited, allowing side-by-side comparison. The main thing one notes is the evolution of camera technology and its handling of colors, amusingly enough.

 

Göbelstraße 2, Hannover

My spouse's grandparents owned a house on this land decades ago. That house has since been replaced by larger buildings.

 

Burg Pfaltzgrafstein, Rhine River

 

Gasthaus Rheingold, Rhine River

 

Assmanhausen, Rhine River

 

Glockenspiel in Munich

 

Odeonsplatz in Munich

 

Karlsplatz in Munich

 

Heidelberg Bridge

 

Heidelberg Castle

New Ohio Exonym Just Dropped

Tell me your game development is done outside of the United States without telling me your game development is done outside of the United States.

As an alumnus of the University of Michigan, I approve of the association of Ohio with "Calamity".

New Google Blogger Features ?!?

**Try our New Beta Features**: Create a more engaging reading experience with the help of Google

Google Search previews: Easily insert visual Google Search previews for popular people, locations, pop-culture and more directly in your blog! In Compose View, look for the ‘G’ button in the editor tool bar to get started.

That is the notice greeting me at the top of draft.blogger.com today. After years of not noticing any change in the service at all, it is now getting search previews.

Honestly I would have expected any sudden burst of activity in Google Blogger to be more distinctly AI-related, part of someone's promotion packet to sprinkle LLMs anywhere and everywhere.

EasyPASS and entering Germany

If you've ever flown into Germany you've seen the two lines at customs and immigration, one for citizens of the European Union and one for non-EU citizens. The non-EU line is often longer and slower, though not exceptionally so at the times I've been through. Nonetheless in a family like ours, where the rest of them go through the EU line and I wait in the non-EU line, it leads to some extra complexities in travel.

EasyPASS is a program to enroll passports from several non-EU countries including the United States, South Korea, and Taiwan to be able to use the electronic readers in the EU line at German airports. One fills out a form to submit at an airport with an EasyPASS office, including Berlin (Brandenburg), Köln/Cologne/Bonn, Dusseldorf, Frankfurt, Hamburg, Hanover, München/Munich, and Stuttgart.

I enrolled at the Munich airport in July 2025, where EasyPASS is handled at the police substation. Follow the signs for the Politzei office, which is at the far end of the airport where there are a number of restaurants and shops. You ring the buzzer for admittance.

It is helpful if you speak a bit of German, but the police stationed at the airport have to deal with international travellers every day and understand English well. They were quite helpful in correcting a mistake I'd made in filling out the form. They then took my US passport to enroll in EasyPASS.

I don't have an outcome to report yet, it will likely be some months until our next trip to Germany to try using the EU line at the airport.

On the Nature of Microservices

Microservices entered the lexicon of systems engineering a number of years ago, breaking up a system which might once have been delivered as a single large binary — though usually with separate relational database at least — to instead consist of a series of small microservices each performing a specific function and communicating amongst themselves to provide an overall service.

In my experience at least, moving to a microservices architecture does solve real problems but the nature of the problems it solves are as much organizational as technical.

In a very large engineering team all trying to work together to deliver a solution, one frequently loses velocity simply because of the number of teams jostling against each other:

1. The release process grows over time, and tends to add process of the form "make sure that problem never happens again."
2. Rollbacks roll back everything. When every team has P0 deliverables, no team has P0 deliverables.
3. The internal architecture might have been carefully planned... or might not. Even without a "if I can call it, I can use it" mentality, there still can be significant underspecification.

 

Moving to Microservices

A team which moves to microservices, devoting considerable effort to do so, has every incentive to solve these issues:

1. The release process for each microservice can be (mostly) decoupled with disciplined versioning of API between producers and consumers.
2. Rollbacks impact only a portion of the overall service.
3. The interfaces between microservices will have an API boundary, though Hyrum's Law still applies that un-promised behavior can become a load-bearing dependency.

The tradeoff is that one now has a distributed system, and distributed systems are hard.

• Debugging is much more likely to cross multiple processes.
• The 95% and 99% tail latency will suffer, as long code paths likely incur extra cross-process messaging.
• A robust design will degrade if subsystems are unavailable, transforming the potential for outage into more frequent partial systems failure.

If the problem being solved is "maximize effectiveness of a large engineering team" then these are perhaps good tradeoffs. One has the resources to develop tooling for debugging and latency and reliability. If one has further chosen to deploy those services via an orchestration system like Kubernetes, one has the personnel to cover the operational burden of that too.

If one doesn't have the personnel to cover the cost, microservices become a more questionable choice. Fundamentally: delivering via monolithic binary is not inherently bad. It isn't automatically a poor choice. It isn't poor engineering.

How to deliver software is influenced by the size and composition of the team delivering it.

Try Turning the Train Off and Back On

Today I rode the Bay Area Rapid Transit train from the peninsula up to San Francisco. Our stop at the 24th and Mission station was unusually long. The conductor announced on the speaker that they were rebooting part of the train computer.

The universal first troubleshooting step now extends to turning the train off and back on.

One Year of Electrified Caltrain

In November 2020 California voters passed Measure RR to fund electrification of Caltrain down the San Francisco Peninsula. After several years of construction, the new electrified trains entered service on September 21, 2024: exactly one year ago at the time of this writing.

The electrification measure was an audacious plan for Caltrain to recover from the Covid-driven disruption in travel patterns by radically improving the service. The electrified fleet would provide more frequent service because the new engines would accelerate and decelerate far more strongly than the diesel locomotives did. The rolling stock would additionally be refreshed with new passenger cars.

So: did it work? Based on ridership data from the last year, to me it certainly appears so.

The large drop in ridership in 2020 is due to Covid. I tried to show the slope by drawing red lines in the few years between Covid and electrification, and between electrification and now. The rate of increase in ridership changed markedly for the better in almost exactly 9/2024 when the lines were electrified.

Ridership has not yet returned to pre-Covid levels, but now appears to be on track to do so if trends continue.

Android Signal Keyboard Privacy

Android keyboards can be quite sophisticated, including learning of commonly used words or languages. Some of these result in uploading what you enter to a service you may not know about. The Signal app on Android includes a setting to say that its keyboard input should not be uploaded.

Malicious keyboard apps can ignore this, but if a malicious keyboard has made its way onto your device I think you have bigger problems.

The tradeoff: if you use speech-to-text on the Android keyboard, it will no longer work. The microphone will be greyed out and will bring up a small message saying "This app doesn't support voice input." The stock Android keyboard apparently has no on-device voice processing.

I learned of this from Liz Fong-Jones' Bluesky feed.

Continuous Improvement in LLM Code Generation

One week ago, I wrote:

"I wish wish wish that Claude Code would automatically populate a .gitignore for node_modules. Not for the first time, I checked 437 Megabytes of code into git and had to rewrite the history to remove it."

I used Claude Code to create a new frontend project, using Qwik this time, and what do I see?

dgentry@llm:frontend$ cat .gitignore
# Build
/dist
/lib
/lib-types
/server

# Development
node_modules
.env
*.local

...

I don't know if this represents something which the Claude Code team specifically made happen since the last time I had it generate code like this, or if the training data of Qwik codebases is so much more likely to have included node_modules in their .gitignore file.

It is one of the perverse things about use of tools like this: we tend to give credit to the tool, and not the community which created the information upon which it relies.

Passport Cards as Proof of Citizenship

In November 2024 we ordered Passport Cards for the first time. The cards arrived 18 days after we mailed in the forms, without paying for expedited service nor even for express mail.

The Passport Card is a stiff plastic card, slightly thicker than our driver's licenses. It is specifically not valid for international air travel, though it can be used to board a domestic flight and is Real-ID compliant. It cost $30, versus $130 for a Passport Book, at least as of the timeframe we ordered in late 2024.

Most importantly though: it is much more reasonable to have a Passport Card with you at all times than it would be to carry around a Passport Book, and the card is a valid proof of citizenship. It can be used within the United States, can be used for travel within the Americas, and will allow re-entry into the US even if you have lost the regular Passport Book.

One caution: when it comes time to renew, both the Passport Book and Card will need to be turned in for renewal. Keep good care of both, if one is lost then the renewal of the other becomes a Lost Passport event which requires DS-64 and DS-11 forms to replace. The DS-11 requires birth certificates and other proof of citizenship, just like getting the passport for the first time required.

A Passport Card is a good way to have proof of citizenship with you at all times.

Konsulatstermine für Reisepässe

Upon acceptance of a Staatsangehörigkeit § 5 declaration, making one a German citizen, the next step is generally to order a German passport called a Reisepass. This requires filling out the form and bringing the Urkunde über den Erwerb der deutschen Staatsangehörigkeit durch Erklärung and passport photos to the responsible Consulate in a passport appointment.

It can be difficult to get a passport appointment. You keep checking the site and there are never any appointment slots available.

German Consulates around the world add new appointments every weekday at midnight in Germany. For example, that is 3pm in California. If you start polling the appointment site at 2:59pm on Sunday, you have the best chance of seeing new appointments appear and grabbing one before they are all gone. Note that Daylight Savings Time differs by several weeks between Europe and the US, they aren't the same number of hours apart all year.

There are Honorary Consuls in a number of cities who can make copies of your documentation and forward it to the Consulate, which might be easier to get an appointment with if your Consulate is swamped.

As an engineering executive there are a few ideas and practices which I reinforce via repetition to the team, either explicitly at the start of a recurring meeting or implicitly by bringing it up whenever relevant. The first of these ideas is:

The product is not the code, not the features, not the designs.
    The product is that people can use the service for things that are important to them.
The business is not the code, not the features, not the designs.
    The business is that people can use the service for things that are valuable to them.

But the topic of this post is not that. The topic is the second thing I frequently reinforce via repetition:

Get something, anything, working end to end as quickly as you can.
Not even a minimum viable thing. Any thing.

It has been my experience that, as developers, we tend to focus in on one area of a system to explore its requirements and build it out sufficiently until we feel confident that we understand what else will need to be done before moving on to the next piece. This results in a system where the understanding and the plan for development is grown by accretion, each piece layered atop the previous which is left undisturbed by later developments. We might go back and harmonize all of them later... maybe.

It has also been my experience that everything starts progressing more quickly once the system does something, anything end-to-end.

1. We gain perspective on how the whole system will work and apply it to everything we do subsequently.
2. One can make a change and see it function all the way through. Enthusiasm improves productivity.
3. It is far more effective when multiple people work on a system in parallel if they can all see the impacts of each other's work.

Thus:

Get something, anything, working end to end as quickly as you can.
Not even a minimum viable thing. Any thing.

LLMs to Blaze a Trail

With the maturing capabilities of LLM code generation, I tried an experiment with Claude Code. At Google one of the classes in orientation was to construct a web scraper. I asked Claude Code to build a scraper, but an even simpler one: scrape a metric.

In a new scraper directory, create a go program which will scrape a web page formatted
in prometheus metrics format, and extract a floating point value labeled "example"

Create an SQL schema for a timeseries, with columns for a timestamp and a floating point value.

Have scraper connect to a Postgres database and write each sample it collects to the database.

In a new webui/frontend directory, create a web page using React and typescript which will
poll a backend server for changes in a loop and display rows of timeseries data with timestamp,
sample name, and value.

In a new webui/backend directory, create a go program which will handle queries from
webui/frontend and fetch timeseries data from the postgres database.

It produced a small, functional implementation.

scraper	123 lines	Go
backend	169 lines	Go
frontend	127 lines	Typescript
	100 lines	CSS
	43 lines	HTML

A few interesting tidbits:

• It produced no unit tests for the Go code. I didn't tell it to.
• It did produce unit tests for the TypeScript code, even though I did not tell it to. I think this speaks well for the TypeScript community, the training data is infused wth testing as an expected practice.
• I wish wish wish that Claude Code would automatically populate a .gitignore for node_modules. Not for the first time, I checked 437 Megabytes of code into git and had to rewrite the history to remove it.

 

Unit Tests

Having no tests at all sets a bad example. I don't actually want to encourage the construction of large system test suites at this stage of a project, as the effort to keep updating a large test as the system evolves is likely to outweigh the value of the test at this stage. Yet I do want to set the example by ensuring there is something.

In the scraper directory, keep the main() function in main.go but move the rest of the code
to a scrape.go file. Write tests for scrape.go with a local prometheus server and in-memory
database. Check that metrics are correctly stored in the database.

Claude Code generated 377 lines of test cases, including scraping one value and several values. Most of the code was to set up an in-memory database using sqlite and to run a local Prometheus server.

The cost of the first prompt to generate the system and the second prompt to add unit tests: 93 cents.

 

Non-trivial example

That example was pretty contrived. How about an example of a more realistic system which:

1. Implements a protocol connecting to a legacy communications system.
2. Implements a set of modern protocols connecting to current Internet communications infrastructure, to forward messages to and from the legacy protocol.
3. Has a management layer watching all of the connections and can stop or restart them as needed.
4. Has a dashboard and console showing the status and configuration of the system.

Can it produce this? Well... not exactly. I kindof cheated: this is the first thing I attempted, I made up the contrived system later.

The problem is that first step. Claude Code was not much help in producing the first piece, connecting to the legacy system. The tasks there were more like engineering archaeology:

• Trying variations on the digest hash function until the remote system suddenly returned 200 OK.
• Figuring out what portions of the the poorly documented header fields were actually implemented.
• Diagnosing failures when the only indication we get is "Invalid" with no further information about what was invalid.

There just isn't any training data for this, and so trying to rapidly get to a functioning end-to-end system entirely via code generation didn't work. I was able to work on the management layer and the dashboard and so on while still debugging the first piece, but it only started working when that first piece was done.

Could I have set that first piece aside with a mockup, and worked on the rest? Probably, but it was just me not a team and the first piece was the biggest risk. I focussed on eliminating the risk.

In an engineering team, I think I would approach this with a small team whose job is to sketch out the overall system. It might be entirely senior engineers or at least led by a quite senior engineer, and tasked to identify and quantify risks and to plan out a system. That team could multiply its efforts using LLMs to help generate the more well understood portions of the system.

Tell me this looks wrong to you, too.

Claude Code doesn't see it. I mean, of course Claude Code doesn't see it, it has no eyes or other senses. Nonetheless I tried to get Claude Code to fix it by leading it to a solution.

In frontend/ in the Delivery page, align the Save and Cancel buttons vertically.

In frontend/ in the Delivery page, remove the height property from the Save and Cancel
buttons. Put both buttons inside a div, and set the height of the div to 40px.

Neither of these fixed it, because these were not the problem. The actual problem was:

233 .save-button,
234 .add-button {
235   background-color: #48bb78;
236   margin-top: 1rem;
237 }

This was leftover from when the button was elsewhere on the page, and not removed when it moved to be next to the Cancel button. Poking around with Chrome's Developer Tools and looking at the Elements on the page identified it.

On the Persistence of Human Memory

One thing I am finding is that memory of code generated with the help of an LLM fades much more quickly. Some portions of this system were not amenable to getting help from Claude Code — things which involve low level interoperability with existing and legacy systems. There is no relevant material in the training set, Claude Code could not help in iterative debugging in staring at the errors from the legacy system to figure out what to do next.

Those portions of the codebase, those developed with blood and sweat and tears, remain clear in my memory. Even months later I can predict how they will be impacted by other changes and what will need to be done.

That is not true of the portions which the LLM generated. Continuing with the analogy of treating it as an early career developer, I only reviewed the code I didn't write it. As with any code review, the memory of how it works fades much more quickly compared with actually digging in to the work.

(This is better than Claude Code, though, which retains no memory at all of how code has evolved and instead discovers it all afresh at the start of each session).

Treating an LLM like an early career programming partner can provide large increases in productivity, but it also means that one has less personal recollection of the windy path the code took to get to its current state. One must be able to go spelunking. This isn't that much different from a codebase which one has worked on over a long period: little detailed memory of specific portions of the code remain, but an overall sense of the codebase is retained much longer.

Claude Code's 19 cent Parser

A brief prompt:

In authheader.go write a function to parse a SIP WWW-Authenticate header for Digest
authentication. It should return a map[string]string of key:value pairs which are
present. It should handle the case of valueless parameter with no "=" by populating
an empty string in the map.

Write unit tests, including these WWW-Authenticate headers:
1. WWW-Authenticate: Digest algorithm=MD5,realm="example.com",nonce="abcd="
2. WWW-Authenticate: Digest realm="example.com", nonce="efgh=", opaque="1234__", algorithm=MD5, qop="auth"

From this, Claude Code generated quite reasonable parsing code for a SIP WWW-Authenticate header. It did this in approximately one minute of wall-clock time at a cost of 19 cents. This is considerably more quickly and cheaply than I could have produced a similar function.

I made one manual fix: the string comparison for "Digest" and for parameter field names are supposed to be be case-insensitive, and I added unit tests for it. I hadn't specified this in the prompt, and Claude Code didn't figure that out from the mention of SIP.

I remain of the opinion that vibe coding can be a force multiplier for expertise, not a complete replacement for expertise.

 

Wisdom

Returning to an earlier topic: does the code which Claude Code generated exhibit wisdom? Did it have shortcomings which would be harmful? Claude Code came up with the following test cases, and wrote a Go table-driven test case for them.

1. The two I explicitly gave it.
2. Header with valueless parameter
3. Header with unquoted values
4. Empty header
5. Header with comma in quoted value
6. Header with extra spaces

I looked into the handling of unquoted values. The SIP standard says that fields like algorithm or qop which are enumerated in specifications can be left unquoted. What Claude Code generated would allow any field to be unquoted, including arbitrary text strings like realm.

The spec says these values must be quoted. Yet there is also the Robustness Principle, to be liberal in what you accept and strict in what you send.

 

Postel's Law Considered Harmful

Nowadays I think this principle has ultimately been more harmful than good. Over time we end up with a protocol which is only partially specified, where real implementations require a neverending series of quirks handling to work around the behaviors of widely deployed yet incorrect implementations which other implementations have liberally accepted. For new protocols I'm a fan of be strict in what you send and strict in what you accept, to not allow quirks to accumulate. Like barnacles, quirks slow the forward progress over time and tend to cause standrds to bog down and eventually stop even trying to evolve.

But SIP is ancient. In Internet Years it is a centennarian. What should one do about SIP? Being strict in what one accepts would lead to a series of relaxations being added during deployment when engineering philosophy meets harsh reality that there are a lot of barely-compliant production services run by vendors far too large to care what some Internet Rando thinks of their implementation.

 

Epilogue

I did consider whether to just leave it this way, and allow unquoted strings for all fields. Life is too short to fight the weight of Internet Protocol Inertia... but I couldn't do it. That would make my little corner of the SIP world be part of the problem. I made it only accept unquoted strings for algorithm and qop, the two enumerated fields which my system deals with.

In authheader.go:parseWWWAuthenticate() fields named “algorithm” or “qop” may be
quoted or unquoted. Any other field name must have its value quoted to be accepted.

In authheader_test.go add test cases:
1. fields named “algorithm” or “qop” may be quoted or unquoted.
2. Any other field name must have its value quoted to be accepted.