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.