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?