Re: process question (was: LDP paging + IETF 2NN draft comments - some questions I came across while working on editorial issues)

On Wed, Jul 9, 2014 at 3:00 PM, John Arwe <johnarwe@us.ibm.com> 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.
>
> You weren't asking me but even though it might be optional, I think it
would be good to be clear with the reviewers of the spec "where things
stand with 2NN".  So I would recommend marking it as such, at risk seems
ok, then if we do remove it no harm done.

Thanks,
Steve Speicher
http://stevespeicher.me

>
> 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
>
>