Re: Subaddress revisited

[Ned Freed <Ned.Freed@xxxxxxxxxxxx>]

> At the risk of showing how little I know about the big picture (as if
> some of my recent posts had not demonstrated this adequately) I will
> presume to answer Mr. Shockey's question.  (This is particularly risky
> since I did not attend the ietf meeting in December nor have I had a
> chance to review all of the postings that arrived during my vacation.)

Your list seems reasonably complete to me.

> What's left?  In no particular order:

>   - Content-Type for images

TIFF is certainly the devil we know best -- far from perfect, but arguably
better than anything else. As you say it handles existing FAX formats, and
existing software actually seems to do the right thing with it most of the
time.  (The same cannot be said for quite a few other image formats,
unfortunately.)

I think there also needs to be some consideration given to profiling other
types as well, however. Stuff like text/plain, for example, and probably
text/html.

> 	Time to revise RFC 1314.

Agreed.

>   - Content-Type for capabilities (present or desired)

This is a very nasty problem. As others have already pointed out, interactive
negotiation a la HTTP simply isn't possible in general in SMTP because of
multiple hops. But is it worth defining an SMTP extension to do this sort of
thing in the cases where it is possible? I doubt it, but the existance of
certain common usage scenarios could prove me wrong on this point. Or maybe a
better way to do it would be to define a series of attributes that can be
placed in a directory service like, say, LDAP. Getting user agents to actually
pay attention to this sort of thing would be tricky, however.

Regardless of what approach is chosen (assuming of course that the problem
isn't simply ignored), I think Larry is 100% correct in saying that this needs
to be coordinated with HTTP content negotiation, and that if it is to be done
in SMTP is has to be an SMTP extension that effectively places it in the
envelope.
	
>   - Content-Type for confirmation/rejection messages
> 	A method of encapsulating a confirmation/rejection message that:
> 		(a) can be easily parsed automatically;
> 		(b) can be extended to provide additional information in
> 		    future;
	
This, thank goodness, is a done deal. See RFC1892-RFC894 for details.

>   - and finally, a standard syntax for incorporating fax addressing
>     (and yes, even subaddresses) in the email envelope.  This ought to
>     be able to be extended to handle the case in which the IFAX is
>     operating as a gateway to legacy fax machines.  Several suggestions
>     have been floated in this discussion group before so I will not
>     belabour the issue.

I already pointed out that efforts to standardize syntax for local parts  in
the past have not been successful as a standards-track activity. This does not
mean, however, that doing so is a bad idea, just that it has proved problematic
for entirely political reasons in the past. And despite the potential for
trouble in this area I think this is something worth pursuing.

				Ned