On Aug 24, 2007, at 11:23 AM, Alexey Melnikov wrote:
Peter Saint-Andre wrote:
Alexey Melnikov wrote:
Cullen Jennings wrote:
Making this experimental not make much sense to me - there is no
real experiment here other than "will anyone use it" and that
could be said about a large percentage of PS documents. When I
read 2026, this looks like PS.
I agree. If the document is standardizing what is deployed and
there is
no desire to change it, then it should be Informational.
Otherwise it
looks like PS.
Well, folks are using it right now:
http://wiki.jabber.org/index.php/Jabber_Email_Header
I see it in the wild quite a bit, admittedly among people who may
simply
be experimenting with it since they are heavy users of XMPP-based
instant messaging systems.
So perhaps Informational is appropriate.
Again, I'm not averse to designing something more general. And I
think
that experience with this header field may provide useful input to
that
process.
IMHO, if the header is deployed and you publish even an
Informational RFC on it, there is very little chance that existing
implementations would change when a new replacement header is
standardized. And it might be too late already (even before the
Informational RFC is published) to standardize a replacement.
All comments I've seen so far seem to imply that this is useful.
There are existing implementations. So it doesn't seem like an
Experimental RFC is needed, as the experiment is already successful.
I agree it useful and I can't see any reason for it to be
experimental - that's exactly the reason I think it is worth doing. I
understand that when people bring something to a standards body they
typically wish it would not change but often the change is for the
better and allows the standard to have a wider scope and better
longevity than the very initial idea. It's the nature of pre standard
implementations.
Cullen
PS (as of this email being sent, if you check out the headers I think
you will see there is an implementation of the header I proposed
too :-) It's one of the good things IETF can do is help come to
consensus between conflicting pre standard implementations.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf