Re: Late comments on the msgtrk documents

[Eric Allman <eric+msgtrk@xxxxxxxxxxxx>]

The current DSN standards say that ENVID doesn't have to have an
@domain part on it at all -- it only has to be unique to the sending
system.  We are trying to use it to be unique across all messages
that a server might see -- essentially an envelope-level Message-Id.
So I think we're clear for DSNs, but we have a headache for MSGTRK.

Another approach would be to define yet another envelope tag,
e.g., ENVIDprime, that would only be used for MSGTRK.  Seems kind
of ugly to me, but it does avoid this problem.

eric



============= In Reply To: ===========================================
: From:  "Vaudreuil, Greg M (Greg)" <gregv@xxxxxxxxxx>
: Subject:  RE: Late comments on the msgtrk documents 
: Date:  Mon, 15 Oct 2001 15:36:52 -0600

: 
: 
: 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:gshapiro@xxxxxxxxxxxx]
: Sent: Monday, October 15, 2001 3:52 PM
: To: Eric Allman
: Cc: ietf-msgtrk@xxxxxxx
: 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.