Re: [apps-discuss] draft-ietf-appsawg-rfc3462bis: PS or DS?

[Ned Freed <[e-mail]>]

> RFC3462 is currently DS.  There's some question as to whether or not this
> revision qualifies to remain at DS, or forces a recycle at PS.

Why not try for recycle at DS and see what the IESG says?

> The only material change is the removal of a constraint.  On the face of it,
> it would seem that this doesn't disqualify it from remaining at DS.

In general that's not true - removal of a constraint that would affect
implementations generating the format in some way is something I would
see as requiring a reset to proposed.

But since this doesn't affect the associated direct uses of multipart/report -
the constraint is not removed for them - it's difficult to argue that this has
any effect on the usage described in original DSN/MDN specifications. It does
affect new uses of multipart/report for other purposes, but that's fine.

> In addition, Ned has said that many implementations ignore the constraint, so
> it's harmless to remove it.   (Ned, could you elucidate on this in support of
> one position or the other?)

AFAIK in practice nobody ever tried to prevent *indirect* uses of
multipart/report in places other than top-level, e.g., no MUA I'm aware of
will, when incorporating a DSN/MDN as part of a forwarded message, digest, or
whatever, change the media type to avoid violating this constraint, it seems
that implementations have already had to deal with it and haven't had any
problems.

But really, I don't see why we should wring our hands over this. Let's make the
change and ask for a recycle at draft, possibly asking for small exception in
order to relax the constraint without a reset. Make sure this is mentioned in
the last call - let's please not repeat *that* mistake. And if there are no
objections and the IESG goes along, fine, and if not, it gets reset to proposed
and we advance it without republising in exactly six months. I mean, it's not
like we have to do the interop thing over again in this case.

> On the other hand, absent specific data about whether or not this change
> might break anything, it might be more correct to do a turn back at PS until we
> get some feedback (or, perhaps, the absence of it).

Why not let the powers-that-be make this call? That's why they get the big
bucks ;-)

				Ned