RE: Late comments on the msgtrk documents

Why would ACE not cause this same problem with other uses of envid?  It
seems that this is a more general problem.   If we need to grow the
envelope-iD for ACE, we should enlarge it in the DSN specs as well.  

Lurkin' for too long.

Greg V.


-----Original Message-----
From: Gregory Neil Shapiro [mailto:[email protected]]
Sent: Monday, October 15, 2001 3:52 PM
To: Eric Allman
Cc: [email protected]
Subject: Re: Late comments on the msgtrk documents 



eric> I was starting to make this change and suddenly realized that we may
eric> have a conundrum here.  The obvious approach is to increase the length
eric> of the ENVID parameter from 100 to 356.  However, how would I
implement
eric> this when initially submitting the message?  The obvious
implementation
eric> (if the submitter supports MSGTRK) would be to always create a fully
eric> qualified ENVID.  But if that message gets relayed to a non-MSGTRK
eric> agent, that ENVID could be too long, and so you've created a
eric> non-compliant envelope.

eric> I'm starting to lean toward leaving it at 100 characters for this
eric> reason, although that could be problematic (disastrous?) if IDN goes
eric> for ACE encoding, since the expected length of domain names will
eric> go up.

eric> Opinions?

Yes, but it probably won't be liked.  This shows the danger of reusing an
existing protocol element for a new purpose.  I guess MsgTrk will have to
be limited.  C'est la vie.