RE: Second, revised MDN Implementation Report

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