Re: P followup...

On Thu, 11 Dec 2003, Markus Hofmann wrote:

> What about option 4:
>
>   - Stay within limited scope (use IRML as *guidance*)
>   - Dont't worry about interfaces
>   - Specify HTTP rules profile
>   - Do all this by January
>   - Discuss further extensions/modifications in potential re-charter.

I do not think we can produce a _quality_ HTTP rules profile by
January. We can produce a draft, but it will not be ready for an IESG
review and PS status, IMO.

We can try to do the rest this year, and submit the draft to IESG,
but, IMO, we are guaranteed to run into serious Core problems once we
start doing "interfaces" work. We would want to make changes to P
Core, and it would be difficult to do that given current IETF
hit-and-run approach to proposed standards.

	N.B. The above concern is the primary reasons we are doing OCP
	Core and HTTP Adaptation drafts in parallel. And, ideally, we
	should also be doing RTSP or at least SMTP/IMAP Adaptation
	drafts...

HTTP (and probably many more IETF specs with a similar scope) had the
same problem and it resulted in ugly real-world consequences. There is
RFC 2068 defining HTTP/1.1 and RFC 2616 defining ... HTTP/1.1. We have
to deal with old RFC2068 implementations that are not fully upward
compatible with RFC2616 implementations but that cannot be told apart.


If we are to do P Core now, without interfaces, we have to keep P Core
on the charter to be able to revise the proposed standard once we have
interface and implementation experience. Would that be acceptable to
the WG?  IESG? As you know, we currently say that we are not going to
touch, say, OPES architecture document because it has been approved as
an RFC (even though we _now_ know of many problems with that
document). We need to avoid this "don't touch it, it is off our hands"
approach with P Core if we are to postpone interface work. Can we
avoid it?

Thanks,

Alex.




> Alex Rousskov wrote:
>
> > Here is the relevant milestone from
> > http://www.ietf.org/html.charters/opes-charter.html
> >
> > 	Oct 03 	Submit document on rules specification method
> > 	        to IESG for Proposed Standard.
> >
> > I see several options:
> >
> > 	1 Extend the above deadline. This is an admission
> > 	  that the WG failed to schedule a deadline
> > 	  correctly. This does not require AD/IESG review,
> > 	  only WG chair action (AFAIK). This might be
> > 	  blocked by an AD, but since we are delivering
> > 	  on other deadlines, I think our AD can be
> > 	  forgiving.
> >
> > 	2 Submit the current draft now, with minimum changes
> > 	  and no additions. IMO, this is an admission that
> > 	  the WG failed to produce a quality rule language.
> > 	  This requires AD/IESG review which we might pass,
> > 	  but more likely not. We would also have hard
> > 	  time defending half-baked document.
> >
> > 	3 Trim the current draft so that it does not
> > 	  expose known problems and then submit it as
> > 	  Proposed Standard and defend it. I doubt it is
> > 	  possible because the milestone says "specification
> > 	  method" not "rules architecture" or something
> > 	  abstract of that kind. Other opinions?