At 05:09 PM 6/8/2003 -0400, Eric Dean wrote:
Maybe I'm a minimalist, but I'm not sure where 998 characters is a limit for
CRI. Hell, I'm not even concerned about the 78 characters that are
"preferred".
I would prefer not including hash cash, digital sigs, etc within a CRI
model. I'd prefer to keep it simple. that's not to say that these
additional capabilities are not warranted nor provide additional value. In
fact, they may be of such value that they can stand alone.
Should we be building in an extension mechanism that would allow for that?
SMTP for example is a simple protocol, but has an extension mechanism which
allows for a lot more complex stuff.
Regarding SMTP mods..I think we should reserve that concept and develop it
within a subsequent version...but rather focus and define what's currently
at hand. There are a few dozen C/R system that could benefit from an
interworking model
Agreed.
> Now that the issue on the RFC 2822 headers is settled, I would like to
> bring up the issue of MIME and SMTP for CRI. Like I pointed out
> before, in
> my opinion the CRI protocol should utilize both RFC 2822 and MIME
> headers,
> with optional SMTP negotiation. In certain instances, like Vernon stated,
> MIME headers would have to be used when large amounts of data
> (larger than
> the 998 character limit of RFC 2822 headers) need to be transferred.
> Examples would be C/R systems transferring digital certificate chains and
> replying with a single challenge/response message for multiple
> recipients.
> Additionally, SMTP CRI via some ESMTP extension would be useful
> in certain
> cases.
>
> Another very important point, is the need to define the CRI protocol as
> extensible. We need to provide space for implementors to add their own
> features such as hash cash, digital signatures, etc.
>
> Yakov
>
>
> At 10:47 AM 6/8/2003 -0400, Eric Dean wrote:
>
> >I'm pretty sure that it's clear we should move forward with
> proposing a new
> >RFC2822 header. If a BOF wants to throw an X in front of it,
> then so be it.
> >I'll proceed br producing a draft with real 2822-type headers.
> >
> >However, if someone out there is interested, we could interoperate in the
> >meantime using X or optional headers as well as with proposed
> 2822 headers
> >
> > > -----Original Message-----
> > > From: Eric D. Williams [mailto:eric(_at_)infobro(_dot_)com]
> > > Sent: Saturday, June 07, 2003 11:11 PM
> > > To: 'Yakov Shafranovich'; 'Eric Dean'; asrg(_at_)ietf(_dot_)org
> > > Subject: RE: [Asrg] CRI Header
> > >
> > >
> > > On Thursday, June 05, 2003 10:57 AM, Yakov Shafranovich
> > > [SMTP:research(_at_)solidmatrix(_dot_)com] wrote:
> > > > At 11:15 PM 6/4/2003 -0400, Eric D. Williams wrote:
> > > >
> > > > >On Wednesday, June 04, 2003 3:54 PM, Eric Dean
> > > [SMTP:eric(_at_)purespeed(_dot_)com]
> > > > >wrote:
> > > > >8<...>8
> > > > > > ok..optional headers or do we introduce a new one? There
> > > isn't an RFC
> > > > > > 2822
> > > > > > registration process that I am aware of.
> > > > >
> > > > >IMHO the question at this stage is 'optional headers or the
> > > introduction
> > > > >of an
> > > > >new one? Would a comparable RFC 2822 header field be as
> effective?'
> > > > >[..]
> > > >
> > > > Both an "X-CRI" and "CRI" headers should be defined. Until
> the standard
> > > > gets approved, the "X-" headers will be used, once the standard
> > > is approved
> > > > then both the "X-CRI" and "CRI" headers are used. This is
> similar to the
> > > > HTTP protocol where both "gzip" and "x-gzip" are used to
> indicate gzip
> > > > encoding (RFC 2616, section 3.5).
> > >
> > > I understand that, thanks. But the issue I was trying to
> > > interpose is that
> > > perhaps the consideration of which would be more effective for
> > > the proposal is
> > > the type of question that should be asked at this state.
> > >
> > > -e
> > >
>
>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg