- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 09 Jul 2014 17:32:46 -0400
- To: John Arwe <johnarwe@us.ibm.com>, "public-ldp-wg@w3.org Group" <public-ldp-wg@w3.org>
- Message-ID: <53BDB4FE.403@w3.org>
On 07/09/2014 03:00 PM, John Arwe wrote: > Separating this from the 2NN majority-content on behalf of Sandro's > sanity. > > > > 3a: If [1] intends its new Prefer opt-in to be a "true hint" (i.e. > server > > > can ignore it if the server so desires), as currently written, > then our > > > Must Not should be written in terms of that Prefer header IMO; > > FYI, my thinking on this has evolved as I decoupled 2NN from paging > better (i.e. during drafting). As now reflected in the editor's > draft, 2NN is an optional optimization over 303. This was already the > case in the normative text, but I fleshed out the progression in the > new chapter 4 which subsumed and added to 5.2's former example. I > also raised Eric P 3 lists in the course of that drafting ;-) But > basically, since 2NN is optional per-client, in order to sensibly talk > about paging we have to mention both the 2NN and 303 cases in the > server side. > > Process question: is there any value in carrying 2NN as At Risk at > this point? I don't mind it staying that way if there's reason to, > but *if* it is the case that it's optional (it's a Should in the > already-existing normative text, which is now further qualified with > "if the client signals support for 2NN"), then I don't see its removal > as affecting compliance ... which is the usual reason for making > something At Risk. > It's kind of pedantic, but I don't see how we could keep the text without knowing what NN is. -- Sandro > > Best Regards, John > > Voice US 845-435-9470 BluePages > <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe> > > Cloud and Smarter Infrastructure OSLC Lead >
Received on Wednesday, 9 July 2014 21:32:56 UTC