Add Some Clarification on Reporting IDs, Origin

[thegreatfatzby]

Wanted to add some clarity, which also will serve as a confirmation for a question we've had internally, on any limitations on buyer/seller reporting IDs. Added a few others in the neighborhood while at it.

I do want to point out that the buyer/seller reporting IDs are listed in the full spec (https://wicg.github.io/turtledove/) as USVStrings for object declaration, but then DOMString when passed into reporting functions as browser signals. I do see other values go into browser signals as USVStrings, so it seems like either can go in...is that difference intentional?

[JensenPaul]

The USVString changes look good as they match #762.
@qingxinwu, do you know the answer to Isaac's question about DOMString vs USVString?

[qingxinwu]

The USVString changes look good as they match #762. @qingxinwu, do you know the answer to Isaac's question about DOMString vs USVString?

@morlovich Do you know whether this reporting ID can be DOMString instead of USVString? I think so, but want to double check.

We used to use USVString for most places that needed a string. But we changed some to DOMString (example CL) as our spec mentor pointed out that DOMString should be used instead of USVString if we know that the field won't contain unmatched surrogates. As a result, we now mostly use USVString for URLs/origins that need to be parsed (e.g., the allowedReportingOrigins in #762), and DOMString for others. But it turns out we still didn't care much about the difference in some new code, some of which got changed to DOMString in follow up CLs.

[morlovich]

I think I understood spec advice other way around --- that it should be USVString when we put it into URLs? And these IDs are kinda odd since we don't put them into URLs, but people who use them probably would?

[qingxinwu]

I think I understood spec advice other way around --- that it should be USVString when we put it into URLs? And these IDs are kinda odd since we don't put them into URLs, but people who use them probably would?

I think it's the same as what I meant by "we now mostly use USVString for URLs/origins that need to be parsed". Yes, it should be USVString if we put it into URLs, and I was wondering if this field could potentially go to URLs, or contain unmatched surrogates. If it could, then USVString is fine.
I need to make the field consistent in the spec for sure.