I think this fits.
• If the IETF may publish something based on this on the standards
track once we know how well this one works, it's Experimental. This is the
typical case of not being able to decide which protocol is "better" before we
have experience of dealing with them from a stable specification. Case in
point: "PGM Reliable Transport Protocol Specification" (RFC 3208)If we publish something it may or may not look like the current spec but getting some experience with the current spec will inform that decision. John B. On Sep 11, 2014, at 12:55 PM, Phil Hunt <phil.h...@oracle.com> wrote: > Interesting. The definitions in that don't correspond with what ADs and other > groups are doing. > > I heard httpbis using experimental as a placeholder for a draft that didn't > have full consensus to bring back later. > > That was the feel I had in Toronto-that we weren't done but it was time to > publish something. > > Reading the actual definition i would say neither fits. Ugh. > > Phil > >> On Sep 11, 2014, at 8:01, "Richer, Justin P." <jric...@mitre.org> wrote: >> >> According to the guidelines here: >> >> https://www.ietf.org/iesg/informational-vs-experimental.html >> >> And the discussion in Toronto, it's clearly experimental. >> >> -- Justin >> >>> On Sep 11, 2014, at 10:36 AM, Anthony Nadalin <tony...@microsoft.com> wrote: >>> >>> Is "experimental" the correct classification? Maybe "informational" is more >>> appropriate as both of these were discussed. >>> >>> -----Original Message----- >>> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Hannes Tschofenig >>> Sent: Wednesday, September 10, 2014 4:50 PM >>> To: oauth@ietf.org >>> Subject: [OAUTH-WG] Dynamic Client Registration Management Protocol: Next >>> Steps? >>> >>> Hi all, >>> >>> in response to the discussions at the last IETF meeting the authors of the >>> "Dynamic Client Registration Management Protocol" >>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-management-05 have >>> changed the document type to "Experimental". >>> >>> We need to make a decision about the next steps for the document and we see >>> the following options: >>> >>> a) Publish it as an experimental RFC >>> >>> b) Remove it from the working group and ask an AD to shepherd it >>> >>> c) Remove it from the working group and let the authors publish it via the >>> independent submission track. >>> >>> In any case it would be nice to let folks play around with it and then, >>> after some time, come back to determine whether there is enough interest to >>> produce a standard. >>> >>> Please let us know what you think! >>> >>> Ciao >>> Hannes & Derek >>> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
