RE: [Asrg] CRI Header

[Yakov Shafranovich <[e-mail]>]

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:[e-mail]]
> > > > Sent: Saturday, June 07, 2003 11:11 PM
> > > > To: 'Yakov Shafranovich'; 'Eric Dean'; [e-mail]
> > > > Subject: RE: [Asrg] CRI Header
> > > >
> > > >
> > > > On Thursday, June 05, 2003 10:57 AM, Yakov Shafranovich
> > > > [SMTP:[e-mail]] wrote:
> > > > > At 11:15 PM 6/4/2003 -0400, Eric D. Williams wrote:
> > > > >
> > > > > >On Wednesday, June 04, 2003 3:54 PM, Eric Dean
> > > > [SMTP:[e-mail]]
> > > > > >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
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/asrg

_______________________________________________
Asrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/asrg