Path Forwards: one, two, three specs?

[svgeesus]

(This started as a review comment on the First Draft Range Request PR but I think it makes more sense as a separate issue)

General comment: I would like to see some consistency and harmonization in the Introduction and negotiation sections for the Patch Subset and Range Request documents. Currently they read like two different takes on the same problem.

If we are going to continue to have two separate specifications (which is not necessarily optimal) then we need to decide what our approach is:

1. The IFT is the main spec and has everything except Range Request in there. In which case, large amounts of the current Range-Request Introduction, Opt-In Mechanism and IFT Method Selection should be moved to the IFT spec. That avoids duplication and inconsistency but then it seems odd why one method is in a separate spec.
2. The Patch Subset and Range Request specs are peers and describe only the particulars of the two methods; implying that the current IFT spec should be renamed to Patch-Subset.bs and the need for a third spec which contains the (Harmonized) Intro, Opt-In Mechanism and IFT Method Selection (from this Range Request spec) and the Declaring Incremental Fonts, Negotiating Incremental Font Transfer from the current IFT spec.

Alternatively,

3. Same as 2. except all in one spec. To help maintain consistency, this would be my preference.

Either 2. or 3. solves the issue that the two specifications have similar sections but in different orders and with different section names.

To be clear, this will require changes to both the current documents.

[svgeesus]

In terms of a path forwards, as we already have FPWD for the IFT spec, there is value in accepting the PR as-is and then iterating a little to then publish a FPWD (sooner rather than later) on the separate Range Request spec. That gets the early patent exclusion process underway while we work out the path forward and either split into 3 or merge into one.

[svgeesus]

@litherum @garretrieger @vlevantovsky ??

[vlevantovsky]

I've been away (traveling for a few days) and have yet to review the draft "Range Request" PR in details, but I agree that continuing to maintain two separate specs is unnecessary and maybe even harmful to adoption of this new recommendation in the long run. The original decision to split Range Request into a separate document was only made to mitigate the uncertainty of its availability timeframe, and to facilitate the publication of the FPWD and its public review. Now that we have both documents drafted, I believe the best way forward would be to merge them into a single document and have the FPWD republished.

[vlevantovsky]

... publish a FPWD (sooner rather than later) on the separate Range Request spec. That gets the early patent exclusion process underway ...

I am not sure if there are specific Process details that may necessitate this approach, but, considering that we are simply reusing the Range Request mechanism that has been known and widely used in general, I am less concerned about early patent exclusion opportunity here. IMHO, I'd rather get the consolidated update of WD recommendation published sooner in its entirety, even though it may not happen as soon as the standalone Range Request FPWD.

[litherum]

I think my preference is 3 as well, but I'm willing to be flexible if the group prefers 1 or 2.

[svgeesus]

Now that we have both documents drafted, I believe the best way forward would be to merge them into a single document and have the FPWD republished.

Each document is only FPWD once.

considering that we are simply reusing the Range Request mechanism that has been known and widely used in general, I am less concerned about early patent exclusion opportunity here.

In terms of the HTTP Range Request mechanism, yes absolutely.

The reordering of a font for a particular purpose though, is a separate technology.

[svgeesus]

I'm going to ask @wseltzer for advice on the patent policy implications. Note that this is Turkey Week in the US so I would not expect new info until early next week.

[garretrieger]

I would also prefer option 3, everything in one spec if it's possible.

[litherum]

@svgeesus any update on this?

[litherum]

If we assume we're under the requirements that A) a single document cannot have two FPWDs and B) the range-request method should probably have its own specific FPWD, it seems like the only path forward is:

1. Make the range-request method FPWD
2. (Immediately) merge the two specs (and add relevant redirections / explanatory text / etc.)

[svgeesus]

@litherum I discussed this with W3C staff counsel and the consensus was to publish a FPWD and then merge the two specs after that.

[litherum]

let's do it!

[svgeesus]

let's do it!

Needs a minuted decision to go to FPWD.

[svgeesus]

Transition Request for First Public Working Draft

[svgeesus]

Publication requested 18 Jan, expected 25 Jan 2022

[svgeesus]

Range Request was published today

[svgeesus]

Closed by #76