RE: [Asrg] C/R Thoughts: Take 1

>
> 1. C/R systems should preserve subjects through the process.  They
> can add to them if they want, but the original should be there.

I'm not sure that they should..and not sure they shouldn't.  It should be a
configuration option by the administrator to preserve the subject or
originate a new one.  Such a method would be implementation-specific and not
determined by a standard if mentioned at all.

> 2. C/R systems need to have a standard way of identifying themselves
> as such.  This avoids loops, and it let's us shunt them into an
> appropriate handling queue.

Yes, if a message has the C/R headers..it shouldn't be challenged.  Only
challenge messages should use C/R headers.  We've discussed the issue
regarding spammers using them...not using them.  The other recommendation is
that the system be stateful and not constantly return the challenge
messages.  If you send my demo account 20 messages, you get one challenge
back.  Now, that's implementation-specific.  I would not suggest that a
protocol require a system to be stateful..if mentioned at all.  However, I
would recommend that C/R headers result in a suppressed challenge to avoid
loops.

> 3. As I've said before--any system that requires you to do something
> other than just reply (e.g. read a graphic) needs to meet
> accessibility standards.

Yes, agreed.  And therefore, vendors that do stupid things will not sell
their product and Darwinian nature will run it's course.  I'm not sure that
we want to address the body or content of the challenge message..just the
challenge headers.  Again, these are just my thoughts and am widely open to
counter-thoughts.

> 4. If you have a web based confirmation system, you should also have
> an email-based one.  The fact that I can send you email does not mean
> that I can access your web site.  (Think China, think road-warrier,
> think third world.)

Agreed.  I'm not trying to specify a web-based authentication method here or
an SMTP-reply one.  I agree there should be such methods.  I guess, if the
industry is naturally going in a certain direction, I would not intrude on
their liberties.  However, if we all want to interwork...which is really
what I am looking to define...an Interworking for C/R Systems...then  we
should identify the criteria.  Come to think of it, that's ALL I'm
considering.  I just to provide an interworking method and not dictate to
vendors how they should build their own systems...the market will figure
that out.

As a result, I will probably rename the draft to a C/R System Interworking
document.

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg