Re: Second, revised MDN Implementation Report

The corollary, of course, is that if there're any disposition codes that 
you feel need to be kept, >>implement<< them, and then get someone else 
to implement them as well.

	Tony Hansen
	[email protected]

Vaudreuil, Greg M (Greg) wrote:
 > I think this is a matter of degree.  The 1893 status codes offered a
 > hierarchy, where there is value even for unrecognised codes, or
 > stated differently, for not fully implemented codes.  The NDM
 > dispositions are flat, with diverse meanings.  A client that does not
 > recognise a disposition really can't do anything useful, except to
 > dis-splat it is as is for those interfaces where that is possible.
 >
 > I (obviously) agree that the disposition codes need to have
 > demonstated interoperable semantics to be retained. It makes sense to
 > trim the list to only those that have been demonstated to be useful.
 > Keeping a longer list of unused dispositions carries a cost to those
 > that must provide machine translations without any present value.
 > This is not the case with DSN where a default and appropriate phrase,
 > icon, or color can be maintained without needing extra code to
 > support the possibly unused detail digit.  For example, we in
 > voicemail must keep meaningful recorded phrases in each of many
 > languages for each MDN disposition, but not for each status code.
 > Based on this experience, I fully support dropping the dispositions
 > that have not been implemented and are not supported.
 >
 > Greg V.
 >
 > -----Original Message----- From: Keith Moore
 > [mailto:[email protected]] Sent: Monday, September 30, 2002 12:27 PM
 > To: Pete Resnick Cc: Keith Moore; Vaudreuil, Greg M (Greg);
 > [email protected]; [email protected]; Tony Hansen;
 > [email protected]; [email protected]; [email protected]
 > Subject: Re: Second, revised MDN Implementation Report
 >
 >
 >
 >> On 9/29/02 at 10:11 PM -0400, Keith Moore wrote:
 >>
 >>
 >>> I guess I wonder about this logic.  the dispositions don't seem
 >>> like protocol features to me, they seem like status codes.
 >>>
 >>> do we really think we need to deprecate any status code that
 >>> doesn't have at least two implementations currently generating
 >>> it?
 >>
 >> Actually, yes. Insofar as documenting disposition types (or status
 >>  codes) involves documenting their semantics, I really would want
 >> two implementations to show that people were able to implement the
 >> spec without screwing up the semantics. Remember, the extension
 >> mechanism exists so that new types can be introduced. When two
 >> people do get together and agree on the semantics of a new type,
 >> they can document it and bring it along to draft standard (and
 >> perhaps incorporate it into the main document at that time).
 >> Otherwise, we risk having a type that no one can seem to get right.
 >>
 >
 >
 > perhaps you are right, but I think these are far stronger criteria
 > than we've applied to e.g. RFC 1893.  and while I'd love to have more
 >  uniform implementation of 1893 codes, I think that all of the codes
 > (even those that are seldom-used) are valuable and I would hate to
 > deprecate the ones we could not find two implementations for.
 >
 > Keith ---------------------------------------------------------- This
 > message was sent to you, since you are subscribed to
 > [email protected]. You can manage your subscription at
 > http://www.neystadt.org/cgi-bin/majordomo
 >