WA7BNM 2005-11-07 07:24
You're receiving this e-mail because you either commented on the October 30
draft DTD for using XML for realtime reporting of contest scores, or you
expressed interest in the project. If you would like to be removed from this
distribution list, please notify me (you don't have to be on the distribution
list to continue to comment).

A summary of the comments received on the draft DTD and a list of proposed
changes can be accessed through the web site:
http://www.hornucopia.com/xml4contestresults.html

Please review and comment on the proposed changes so that we can move to a
second draft of the DTD. Comments can be sent to the xml4results[at]hornucopia[dot]com
distribution list, or directly to me.

As a reminder, the goal of this effort is to establish a standard means of
periodically communicating contest scores, and related information, from participants
in a contest to realtime scoreboard(s) by means of XML. The standard will be independent
of any specific contest logging application, scoreboard application or operating system.
//
//----------------------------------------------------------------------
//
W0MU 2005-11-07 10:00
I think the SS CW test run was a good start.

If we are going to use this as a means to generate interest in contesting
then I think we need to consider adding in rate meters and the last 5 or 10
qso's.  Obviously some programs may not lend themselves to this data easily.
I also believe that the operator should decided what information they want
displayed. 

Looking at the page now and then did not really inspire me.

There was some concern about what data should be displayed on the web page
and what should not.

SS Power level - If someone wanted to cheat they could get this off the 3830
archive list if the participant submitted a score.  If there are enough
participants using live scoring there will be a need to separate the A, B ,
U and M classes.

SS Section - Once again this is information that could be gathered from the
FCC Database, 3830, Qrz, etc.

Last x worked - Should the band be included if this is implemented?  I see
no issue with showing 20m.  Anyone wanting to find me will have to tune the
band and they might work a few other stations looking for me.

Mults - For sweepstakes it might be fun to know what mults a particular
station needs.

Security - A secure login feature to the main data server should be
required.

Records - If we had records for many of the contests the live page could
report that a particular score might be a new record. 

Some of my ideas are probably outside the initial scope of the project.  I
see this as a way to really generate some new interest in contesting.  I
think it would be great if we could take the top 10 or 20  scores and port
them to other websites such as eham, comtesting.com, personal web pages and
maybe even the sponsors own sites assuming of course they would want to
display this information as it was happening!

Thanks to Bruce and Dave and everyone else for N1MM logger CW test server
space and application!
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-07 10:17
Why does security keep coming up?  The current 3830 score reporting system
has no security and yet it is widely used as a definitive source of claimed
scores.  Even the final log submission to the contest sponsors has no
security, anyone could send a log with anyone's call in it and there would
be nothing but an email address to trace it back to, and those are easily
faked or obtained for one time use.  adding some kind of accounts, login,
passwords, or certificates seems way beyond what is needed for this.  Please
don't make this another lotw security fiasco!
//
//----------------------------------------------------------------------
//
W0MU 2005-11-07 10:45
You have to register with ARRL, Contesting.com, QRZ, etc.  This probably is
handled outside the reporting application in this scenario.

I think that there should be some way to ensure that what you are uploading
is your score and not overwriting someone else's.  Nothing more.

With email you are not overwriting someone else's score.
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-07 10:55
I could send in a contest log with w0mu as the callsign and it would replace
whatever you had already sent in... and I would get the ack message so you
wouldn't even know it happened until the official high claimed or final
results were posted.  For submitting contest logs to the arrl or cq or any
other organization who's contests I have been in there is no
pre-registration, no verified email address, no encryption key, no pgp
signature code, or any such sender verification.  You just address an email,
attach the Cabrillo, and away it goes... and they even handle replacements,
just send another copy and it replaces the first one, the exact same way.
Why should collecting unofficial results be any different?  Or any harder
than the present 3830 method that just takes whatever you put in on a web
page without user verification?
//
//----------------------------------------------------------------------
//
Fabian Kurz 2005-11-07 11:13
On Mon, Nov 07, 2005 at 11:45:49AM -0700, Mike Fatchett wrote:
> You have to register with ARRL, Contesting.com, QRZ, etc.  This probably is
> handled outside the reporting application in this scenario.
> 
> I think that there should be some way to ensure that what you are uploading
> is your score and not overwriting someone else's.  Nothing more.

Following the KISS principle, I'd try to avoid it at any cost to
require a registration.
Neither do I think that there'd occur any abuse without registration,
nor that it'd be possible to make a registration/authentification
system, that really works and is comfortable to use.  Hardly anybody
would bother to send a copy of the licence or any other proof just to
participate in this live scoring system.

If there actually shows up any kind of abuse (which should quickly be
detected and is relatively harmless), it's worth to think about
restricting the access.

Just my 2 cents.

Btw: I will implement the XML format to my WinTest score grabber
(http://fkurz.net/ham/wtscore/) , also a display of the last X QSOs,
QSO-rate would be trivial to implement...
//
//----------------------------------------------------------------------
//
W0MU 2005-11-07 11:33
Good points Dave.  I never thought about someone else sending in a bogus log
to the various email addresses.  That is a bit disconcerting now that you
bring it up.
//
//----------------------------------------------------------------------
//
PC5M 2005-11-07 12:29
Comment 14 - add distance and azimuth indications (need to understand how
this is relevant to realtime results reporting)
 
Although not in line with your initial idea (only publish the score) I would
like to "use" the DTD/Method also to publish the realtime log. For VHF, distance
and azimuth are on a per qso base interesting fields to publish. 
 
I do know solliciting qso's via the Internet is prohibitted for international
contest, for local contests (in EU) it is allowed.
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-07 12:43
I would say at this time that is beyond the scope of the dtd.  There is nothing
else in there that describes per qso information and would not fit into the current
scope of displaying scores in real time.  to add qso data would require a whole new
set of data that would have to include descriptions of all the possible log details
which is a whole new can of worms in itself.
//
//----------------------------------------------------------------------
//
W9WI 2005-11-07 22:25
"Proposed Changes to 2005-Oct-30 Draft DTD
1. Use verbose element and attribute names."
"8. Change geographic designation hierarchy to provide broader
generalization."

In general makes sense.

Should the various location elements be children to a general required
 element?

"mlt mult"
or 'multiplier'?

"2. Add web link element."
"3. Add comments element."

Agreed.

"5. Add VHF and above band designations."
"        * Use frequency designators for all bands, in units of MHz
below 1000 MHz and in units of GHz above 1 GHZ
          Designations would be: 1.8, 3.5, 7, 14, 21, 28, 50, 144, 222,
432, 903, 1.2, 2.3, etc."

For consistency I prefer this latter option.  In fact, might it be best
to stick with units of MHz on *all* bands?  (24000 MHz is not an
unmanageable figure and I suspect the number of transmissions that will
include higher frequencies will be VERY small!)  

"The following comments require more discussion:
    # Comment 5 - security function/authentication"

Probably overkill at this time.  That said, maybe now is the time to
select a scheme, defining it as optional, so that if authentication
proves necessary in the future there is a standard way of doing so.
//
//----------------------------------------------------------------------
//
WB0WAO 2005-11-08 06:21
Let's not replicate the security protocols of LoTW!  What is needed is a transparent
method that identifies the station uploading the current scoring that cannot be
easily spoofed.  As a possible solution what about the following protocol:

The contesting software will identify the uploaded data by using the call that is
entered into the contesting software for the purposes of that contest.  The contesting
software will then use that as the "user id" for the data being uploaded.  The only way
that you could spoof that is to take your contest software and change the call that you
are running underl.   

This should be a simple method of verifying the data being uploaded without having to go
thru the hassle of registering, getting a unique "key", etc.

To enable this feature, one should only have to click a check box in the
configuration/setup of their contest software and make sure that the correct URL for the
reporting site is there.  That should be the end of it!

Bottom line - keep it simple and easy to use and as transparent as possible to the user!
//
//----------------------------------------------------------------------
//
WB0WAO 2005-11-08 07:11
I think that the ability to support RSS feeds is a good idea and should be explored.
I could see several uses for this.

First, this could possibly "complete the circle" by giving the contest software developers
the ability to receive RSS feeds and create a "leader board" that is integrated with the
contest software.  You could see in "real time" (for example) the top 5 in your entry class
as well as your score.  

Now that could be motivation !

Second, I also see the possibility of real timing the scores to other external sites, like
the contest sponsors, etc.

I am sure that there are more uses for RSS feeds - probably some that don't even exist yet!
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-12 11:29
Will the web site we used for ss cw be up for ss ssb?  How about for cqww
cw?  Will there be changes to the dtd before then?
//
//----------------------------------------------------------------------
//
W9WI 2005-11-12 13:09
On Tue, 2005-11-08 at 09:11, Dennis Ponsness wrote:
> I think that the ability to support RSS feeds is a good idea and should be 
> explored.  I could see several uses for this.

I guess I would think (while possibly expressing some ignorance towards
RSS) that's outside the scope of this discussion?

I think what Bruce is trying to accomplish is a protocol for
transmitting results from the competitor to the centralized server. 
What the server does with those results is up to the server.  If there's
a point in having a RSS feed (and IMHO there is) it might be appropriate
to discuss that protocol in a separate thread.
//
//----------------------------------------------------------------------
//
N1MM 2005-11-12 13:56
I originally suggested this.  Wouldn't it be cool if
ARRL.ORG and Contesting.com showed claimed scores
during a major contest? Wouldn't that encourage
participation in reporting scores? RSS might make it
easier for them to do that.

Is it the first thing that needs to be done? No, but
some consideration of it might make for a better
design.  I have no experience with RSS, but the concept
seemed a fit with contesting reporting.
//
//----------------------------------------------------------------------
//
WA7BNM 2005-11-13 06:04
At 11:29 AM 11/12/2005, David Robbins K1TTT wrote:
>Will the web site we used for ss cw be up for ss ssb?  How about for cqww
>cw?

Yes, we can continue with the still experimental POSTing application and
scoreboard if we have agreement on the next version of the DTD. We've been
concentrating at the moment on how to format the data reported by a contestant
during a contest, but we still need to have a discussion about the method(s)
by which this data will be communicated between contestant and scoreboard(s).

>Will there be changes to the dtd before then?

I hope so. I'll be posting my own comments later today and will also post a
summary of all comments provided to-date via the distribution list or directly
to me. I'd like the next version of the DTD to be solid enough that future
changes will be additive, rather than modifications. However, it may still
take a couple of versions to get to that point.
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-13 07:13
For the transmission method I kind of like a simple http POST.  That is
probably generic enough that most apps could handle it simply enough.

There are of course a bunch of methods to transfer data:
1. http post the xml data
2. http put a file of the xml data
3. ftp put a file of the xml data
4. n8vw's xml-rpc methods 
5. some other rpc method
6. a .net web service
7. a generic tcp connection without http, just connect to a port, send xml
text and go away.
8. udp datagram of xml text to server with or without ack mechanism
9. more??

some other thoughts:

I would highly recommend against requiring accounts and passwords.  Since
there is no security for even submitting your final log to a contest sponsor
why should collecting unofficial scores require it?  it will just make more
work for the user to sign up ahead of time and then add the user name and
password to their logger configuration... this should be as transparent as
possible to the user, hopefully just a single checkbox to turn it on and
maybe a couple fields for comments, their webcam link, or other station url.

I think it would be best to keep the return of results separate from the
sending of scores.  While it is possible with most of those methods to
return current results I think it would probably be best to keep that
function separate.  Let the app make a separate http/get, or subscribe to an
rss feed, or just let the user open a web browser to a results page when
they want it... just don't push results back for each posting automatically,
this should simplify both the client and server apps and give the user more
control over the process.
//
//----------------------------------------------------------------------
//
N1MM 2005-11-13 08:05
Ditto.  The point here is to make it easy for three key constituencies:

1. Log program authors
2. Users
3. Non-participants

#1 is solved by making the standard as simple as possible to implement. I
agree with Dave that http post is probably the simplest.  Others could be
added at specific logging program authors' request.

#2 means that no sign up should be required.  You'll lose at least 80% of
the potential users by doing that.  If it starts getting hacked, security
can be added.  How badly will it
be hacked if you refresh your score every 10 min or so?

#3 is the reason for RSS.  We want participants AND non-participants to be
able to see scores real time.  Participants will just go to the scores web
site.  Non-participants need marketing to pique their interest.  Here is
where an RSS feed to contesting.com or even QRZ.com would act as an
incentive.  RSS makes it easy for sites with a minor interest in contest
scores to integrate them into their site.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-13 13:51
On Sun, 13 Nov 2005 15:13:32 -0000, "David Robbins K1TTT" 
wrote :
> For the transmission method I kind of like a simple http POST.  That is
> probably generic enough that most apps could handle it simply enough.

Http post is great.

> There are of course a bunch of methods to transfer data:
> some other thoughts:

Email.

> I would highly recommend against requiring accounts and passwords.  Since
> there is no security for even submitting your final log to a contest sponsor
 ...snip...
> possible to the user, hopefully just a single checkbox to turn it on and
> maybe a couple fields for comments, their webcam link, or other station url.

The reason for using some kind of security is believeability of the data. 
If the user self-selects into the system then the data is more likely to be
honest to goodness real data and not something made up.  I give you packet
has an example of a service gone bad.  There is nothing out their stopping
someone from injecting thousands of junk packet callouts into the system. 
Stuff like that just turns people off and makes the services less useful.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-13 14:23
On Sun, 13 Nov 2005 11:05:23 -0500, "Tom Wagner"  wrote :

> Ditto.  The point here is to make it easy for three key constituencies:
> 
> 1. Log program authors
> 2. Users
> 3. Non-participants
 ...snip...
> agree with Dave that http post is probably the simplest.  Others could be
> added at specific logging program authors' request.

The only problem with HTTP post is that it requires the post varible to be
the same for everybody.  With xml-rpc the services are discoverable. 

> #2 means that no sign up should be required.  You'll lose at least 80% of
> the potential users by doing that.  If it starts getting hacked, security
> can be added.  How badly will it
> be hacked if you refresh your score every 10 min or so?

If the site is on the open internet, expect it to be probed by everyone and
everybody.  Build in security from the beginning and don't tack it on at the
end.

Probably the way to do this is to require the first post to contain a key
that will be used on each subsequent post to tie the data to the source. The
length of the key would of course have to be defined.  I would use the MD5
hash as a standard.
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-13 14:39
> From: Pat Collins N8VW
> The only problem with HTTP post is that it requires the post varible to be
> the same for everybody.  With xml-rpc the services are discoverable.

It is not necessary for the post variable to be the same, the site that
bruce had up for ss cw didn't care what the variable name was as long as it
had the xml data.

> > #2 means that no sign up should be required.  You'll lose at least 80%
> of
> > the potential users by doing that.  If it starts getting hacked,
 ...snip...
> The
> length of the key would of course have to be defined.  I would use the MD5
> hash as a standard.

If the post has to satisfy the dtd format and match the current contest(s)
that are being collected in order to be processed then the chances of
someone posting fake data accidentally or while just hacking around is
probably pretty small.  As far as malicious postings, that would be possible
even with a login system or hash code, if someone really wants to screw up a
system there is very little that can be done short of the lotw style
encryption type system.

And again, since there is no such security required for either the 3830
claimed scores or even for the final log submission to the checkers, why
should this be any more secure or difficult??
//
//----------------------------------------------------------------------
//
N8VW 2005-11-13 14:53
"David Robbins K1TTT"
wrote :
> It is not necessary for the post variable to be the same, the site that
> bruce had up for ss cw didn't care what the variable name was as long as it
> had the xml data.

Good.

> If the post has to satisfy the dtd format and match the current contest(s)
> that are being collected in order to be processed ...
...snip...
>... really wants to screw up a
> system there is very little that can be done short of the lotw style
> encryption type system.

When I speak of malicious posting I'm not talking about someone tricks up
their score to make themselves #1 on the list, I'm talking about someone
sends data specifically designed to DOS or crash what they are sending the
data too.  

> And again, since there is no such security required for either the 3830
> claimed scores or even for the final log submission to the checkers, why
> should this be any more secure or difficult??

3830 is an email list.  The final log submission's are verifiable.  I don't
want to create another packet nightmare nor see long postings on cq-contest
about how on-line scoring is a failure.  

BTW, what I proposed was more secure and not difficult.  The user would have
to do nothing.  The software would only have to generate a key and continue
to use that for posting.  MD5 was suggested since it is a fairly common tool
for such purposes.
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-14 04:04
> From: Pat Collins N8VW
> sends data specifically designed to DOS or crash what they are sending the
> data too.

You aren't going to stop a dos attack with a key in the data.  There is
nothing in specifying the data or how it is formatted or transmitted that
will stop things like syn flood attacks or someone using a properly setup
program from sending a flood of bad data.  As long as the dtd is public and
the communications method is published so its easy for all the different
logging program authors to use there is the possibility of someone who wants
to trick the system to do so.

> > And again, since there is no such security required for either the 3830
> > claimed scores or even for the final log submission to the checkers, why
 ...snip...
> to use that for posting.  MD5 was suggested since it is a fairly common
> tool
> for such purposes.

so consider this a mail list also.  What is different, users are sending
claimed scores.  They are just doing it more frequently than once a contest.
And as I have pointed out in mail that you probably missed, final log
submissions are not verifiable.  There is no way to absolutely prove who
sent a submission, and anyone could generate a bogus one and submit it to
replace a real one from anyone else... and the real participant wouldn't
know until the final results were posted.  Now, since we aren't seeing
problems like that on the 3830 list or in submissions to log checkers I
would contend that we keep this system as simple as possible.  Embedding an
md5 hash code and reusing it is just as good as embedding a random number.
I would say to use the ip address to match up submissions from a call sign,
but that is not valid either, in my tracking of spotting abuses it is common
for one user to have 2 or more ip's during a contest from a dynamic ip pool.
Assigned user names and passwords without LOTW type verification is again no
better than random numbers, anyone can claim to be any call and how are you
going to prove it one way or another.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-14 05:32
On Mon, 14 Nov 2005 12:04:15 -0000, "David Robbins K1TTT" wrote :
> You aren't going to stop a dos attack with a key in the data.  There is
> nothing in specifying the data or how it is formatted or transmitted that
 ...snip...
> logging program authors to use there is the possibility of someone who wants
> to trick the system to do so.

Yes your not going to stop this, so that is why I'm all for a user having to
self-select into posting the scores and that it shouldn't be just check a
box and go.  If not then what is the point of all this.  If the data isn't
going to be believable than why bother.

> so consider this a mail list also.  What is different, users are sending
 ...snip...
> better than random numbers, anyone can claim to be any call and how are you
> going to prove it one way or another.

IP's can be traced to the owner of the net-block.  If the ip's are in the
same net-block then they are probably coming from the same person.  
Services like TOR make tracing via IP pretty much impossible.  

Seems we have several levels of security at issue here and the question is
how far to go.   My vote is for user name/ password with users
self-selecting to push their scores.  I think just having the score posting
open with no security makes the data worthless and this whole project
pointless.   Yes, it may work and be useful, but in the long run if it is so
easy that someone can use whatever call they want than we've just created
another system that people are going to do nothing but complain about.  I'm
all for easy, but what is so hard about the user having to register their
callsign so someone else can't abuse it?
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-14 05:54
> From: Pat Collins
> all for easy, but what is so hard about the user having to register their
> callsign so someone else can't abuse it?

because, as tom pointed out you will lose probably 80% (I think more) of the
possible participants if they have to sign up in advance and do any type of
extra configuration to make it work.  I know that I wouldn't bother signing
up for such a system. I don't need another user name and password to keep
track of, but if all I have to do is check a box I would use it.  its going
to be hard enough to get some of the high scoring operators to participate
without having to get them to register and configure something else.  I also
fail to see why anyone would bother abusing a system like this, I know there
are some sicko people out there on the spotting network, but if you ignore
them they go away... without feedback to them (which this type of reporting
system wouldn't have anyway) they get no satisfaction and give up quickly.
//
//----------------------------------------------------------------------
//
N4ZR 2005-11-14 05:58
David Robbins K1TTT wrote:
>system wouldn't have anyway) they get no satisfaction and give up quickly.

I'm with Dave on this - potentially, the scoreboard is an important marketing
tool for the sport -- we want to make it as nearly painless as possible for
people to say "yes."  Unlike LOTW and DXCC, there would be no permanent damage
done by a breach or two.  Don't do anything that would preclude adding some sort
of security later if it proves necessary, but let's start simple and not
over-anticipate problems.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-14 06:41
N4ZR wrote:
> I'm with Dave on this - potentially, the scoreboard is an important
marketing tool for the sport -- we want to make it as nearly painless as
possible for people to say "yes."  Unlike LOTW and DXCC, there would be no
permanent damage done by a breach or two.  Don't do anything that would
preclude adding some sort of security later if it proves necessary, but
let's start simple and not over-anticipate problems. 
>

Thanks for your reply Pete,
 
Using this has a marketing tool for radio sport has everything to do with
this issue.  The first thing I would ask about something like this is if the
data was accurate.  If I we can't answer that with a 100% yes then we not
being honest with our audience. 
 
Can you explain why you think requiring users to pre register one time to
use a system is somehow difficult?  

I don't think I'm over-anticipating anything, the more I think about this
the more realize that this has less to do with security and more to do with
the authenticity of the data and the integerity of the system.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-14 06:56
> because, as tom pointed out you will lose probably 80% (I think more) of the
> possible participants if they have to sign up in advance and do any type of
 ...snip...
> them they go away... without feedback to them (which this type of reporting
> system wouldn't have anyway) they get no satisfaction and give up quickly.

Do you have proof of that 80%.  Sounds like a made up statistic to me.  What
extra configuration are you talking about?  We haven't even discussed how to
make this work, only that you don't want it.   We have to make the benefit
of this out-weigh any preception of being difficulty.  Have the software
generate the key (don't call it a password) and self-register.  After all,
if you can figure out how to post and xml document, posting anything else is
trivial.

I'm going to modify scoreboard.oqp.us so that when posting via xml-rpc or
direct if you don't have an account you can still post, but viewers will
have the option of excluding non-verified content and that content will be
clearly marked.
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-14 07:27
> From: Pat Collins N8VW
> have the option of excluding non-verified content and that content will be
> clearly marked.

of course its made up, but based on discussions of this in the past.  The
extra configuration would be adding the user name and password to the logger
setup... which of course also raises questions of password security and how
to save it on the user's machine, just too many possible problems and no
perceived benefit to even make me want to bother with it.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-14 07:50
"David Robbins K1TTT" wrote :

> of course its made up, but based on discussions of this in the past.  The
> extra configuration would be adding the user name ...
...snip...
> to save it on the user's machine, just too many possible problems and no
> perceived benefit to even make me want to bother with it.

Dave,

Then why use it if you know it is not valid data?  

I guess you missed it when I said that the sofware could generate that
information.  After all it probably already has the callsign and maybe even
the persons email address.  I guess you also skipped over my thoughts that
this is whole project is completely meaningless if the integrity of data is
in question.  What are your thoughts on that?

Again, this isn't about security, but integrity of the system.  We want the
viewers to believe that the data is true.  That what they are seeing
reflects the current standings and that we can say at the end who stands to
win.   

If we want to take about security then we should probably start working with
cacert.org and require 3rd party verification for certificate generation and
wrap everything up in ssl/tls.
//
//----------------------------------------------------------------------
//
N4ZR 2005-11-14 08:43
Pat, my point was this - if you have 100 scores in a class on the scoreboard,
and one is bogus, it is a transitory problem and not really very important to
the overall effect.  Moreover, it's only for that weekend, unlike DXCC which
is cumulative.  After the weekend, 3830 and the contest sponsors take over.
As Dave points out, there is no security on any log submission robot, and yet
in the 5 years plus that they have been in use I have not heard of a single
instance of someone submitting a log purporting to be from someone else.

Of course, it is impossible to judge in advance whether a requirement to receive,
maintain, and use a password in order to report your score will prove to be a large,
medium or small deterrent to participation.  I personally believe that a one-time
registration requirement would be less of a drag than a requirement to log in or
otherwise authenticate each time you log on, but it would slow some people down,
I'm sure.
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-14 08:48
Ok, enough.  I think we will have to agree to disagree on this.  I see no
reason to burden either the user or the software with anything more than is
required now for 3830 submission or official log submission, which is
nothing.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-14 09:17
Pete Smith wrote :
> Pat, my point was this - if you have 100 scores in a class on the
>scoreboard, and one is bogus, it is a transitory problem and not really very
>important to the overall effect.  Moreover, it's only for that weekend,
>unlike DXCC which is cumulative.  After the weekend, 3830 and the contest
>sponsors take over.  As Dave points out, there is no security on any log
>submission robot, and yet in the 5 years plus that they have been in use I
>have not heard of a single instance of someone submitting a log purporting
>to be from someone else.

I'm sure it gets lots of spam though. 

> Of course, it is impossible to judge in advance whether a requirement to
>receive, maintain, and use a password in order to report your score will
>prove to be a large, medium or small deterrent to participation.  I
>personally believe that a one-time registration requirement would be less of
>a drag than a requirement to log in or otherwise authenticate each time you
>log on, but it would slow some people down, I'm sure.

I think you are confused as to what I am talking about.  With automated
process like xml-rpc yes, the request would have to contain the
authentication information, but you would only have to set that up once.
This is not hard or difficult.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-14 09:23
"David Robbins K1TTT" wrote :

> Ok, enough.  I think we will have to agree to disagree on this.  I see no
> reason to burden either the user or the software with anything more than is
> required now for 3830 submission or official log submission, which is
> nothing.  

How is this a burden?  You still have not explained yourself.  What is so
hard about identifing your self and saying yes, this is my station and my
score that is being posted.  Do you not require a callsign for connections
to your packet-cluster system.  Why not just open that up with no
authentication?   Does not the user have to setup that information in the
software if they use packet?  If not how does it happen?  Doesn't the user
have to register the software that they use?  Don't we have to sign-up for
email accounts and enter a password to send/retreive email?   

Please explain yourself.
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-14 09:54
> From: Pat Collins N8VW
> > required now for 3830 submission or official log submission, which is
> > nothing.
> 
> How is this a burden?  

It is a burden by being more work than not having to do it.

>You still have not explained yourself.  What is so
> hard about identifing your self and saying yes, this is my station and my
> score that is being posted.  

That is done in the xml by identifying the contest/operator/station
callsign.  That should be plenty of id.

>Do you not require a callsign for connections
> to your packet-cluster system.  

No.  swl's who do not have official ham call's can also connect.  There are
even swl categories in some contests for those with no calls.

> Why not just open that up with no
> authentication?   

It already is, in fact there are very few cluster nodes that have any kind
of 'authentication'.  Anyone can connect with any identifier they want
without it being authenticated by any one or thing.  There are a few
restricted nodes that require the sysop to authorize you before sending
anything, but not many of them that I have seen recently.

>Does not the user have to setup that information in the
> software if they use packet?  If not how does it happen?  

Yes, they type in their callsign once somewhere if they have one.

> Doesn't the user
> have to register the software that they use?  

no.

> Don't we have to sign-up for
> email accounts and enter a password to send/retreive email?

Sure, but this is a MUCH higher value service than real time collection of
scores... in fact some people actually have to pay for it so of course it
needs some kind of login.  How much do you pay to enter a contest?  How much
do you pay to view results on the 3830 list or on a sponsor's web site?  How
much are you going to charge for the work of authenticating each user before
they can post scores?

> Please explain yourself.

I think I have done enough and don't want to burden the list any more with
repetitive arguments.  We are not going to agree on this so its time to drop
it.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-14 10:22
"David Robbins K1TTT" wrote :

> > How is this a burden?  
> 
> It is a burden by being more work than not having to do it.

How is typing at most 30 characters once any extra work?

> >You still have not explained yourself.  What is so
> > hard about identifing your self and saying yes, this is my station and my
> > score that is being posted.  
> 
> That is done in the xml by identifying the contest/operator/station
> callsign.  That should be plenty of id.

How so?  I and anybody else can make those up.  Do you really want people
posing as k1ttt?  

> >Do you not require a callsign for connections
> > to your packet-cluster system.  
> 
> No.  swl's who do not have official ...
...snip...
> restricted nodes that require the sysop to authorize you before sending
> anything, but not many of them that I have seen recently.

Then why do you bother spending the extra time producing your emails listing
who did what to whom on the packet-cluster.  Seems to me you are
contributing to the problem.

> >Does not the user have to setup that information in the
> > software if they use packet?  If not how does it happen?  
> 
> Yes, they type in their callsign once somewhere if they have one.

So is this a burden?  

> > Doesn't the user
> > have to register the software that they use?  
> 
> no.

I guess you are only considering N1MM.  A lot of others out there require
registeration.  

> > Don't we have to sign-up for
> > email accounts and enter a password to send/retreive email?
> 
> Sure, but this is a MUCH ...
...snip...
> much are you going to charge for the work of authenticating each user before
> they can post scores?

The question is how much are you going to charge once this service is in
operation.  Why do I feel like that this is still a closed process.  

> I think I have done enough and don't want to burden the list any more with
> repetitive arguments.  We are not going to agree on this so its time to drop
> it.

Then what is this list for?  So we can all just nod our heads in argreement
with the first idea that comes around with out discussing it throughly?  

Like I said before which you failed to even comment on.  I'm willing to
publish xml-rpc specs that don't require authentication, but those entries
will be marked as non-verified, untrusted data and the users will be able to
filter those out.  How is that not agreeing?
//
//----------------------------------------------------------------------
//
K1TTT 2005-11-14 10:44
> From: Pat Collins N8VW
> Sent: Monday, November 14, 2005 18:22 ...snip...
> > callsign.  That should be plenty of id.
> 
> How so?  I and anybody else can make those up.  Do you really want people
> posing as k1ttt?

People pose as me all the time... I ignore them and they go away.

> > >Do you not require a callsign for connections
> > > to your packet-cluster system.
> >
> listing
> who did what to whom on the packet-cluster.  Seems to me you are
> contributing to the problem.

Huh?  How is this related to discussions of real time score reporting.
Those reports are done to bring peer pressure on to abusers who are likely
to submit contest logs that may have violated the contest rules.  They are
not meant to propose or make a case for any kind of restrictions on use of
the cluster system.

> > >Does not the user have to setup that information in the
> > > software if they use packet?  If not how does it happen?
 ...snip...
> >
> > no.
> >
> 
> I guess you are only considering N1MM.  A lot of others out there require
> registeration.

Now you are changing the subject.  The discussion was about cluster use,
which is off topic here anyway I think.  But there are other loggers who
don't require registration or cost anything... including ct.

> > > Don't we have to sign-up for
> > > email accounts and enter a password to send/retreive email?
> >
 ...snip...
> The question is how much are you going to charge once this service is in
> operation.  Why do I feel like that this is still a closed process.

I am not going to charge anything, nor would I write any software for a
process that would cost the user anything.  If it were a closed process we
wouldn't be having this 'discussion', we would have just put up a web site
and advertised how to login and post scores without opening up a published
spec in advance for discussion and testing.

> > I think I have done enough and don't want to burden the list any more
> with
> > repetitive arguments.  We are not going to agree on this so its time to
 ...snip...
> will be marked as non-verified, untrusted data and the users will be able
> to
> filter those out.  How is that not agreeing?

we have been discussing and bruce has been collecting comments on the things
that are important, like what data is needed and how to tag it.  Hopefully
he hasn't been put off by this tangent 'discussion' that keeps going in
circles.  I say again, its time to drop it from the list, I will not reply
to any more posts on the list for this thread... if you still don't
understand my arguments you may query me directly and if I feel like
repeating myself again I may reply.
//
//----------------------------------------------------------------------
//
N2IC 2005-11-14 11:29
ENOUGH !

Take your little squabble off-line !
//
//----------------------------------------------------------------------
//
N8VW 2005-11-14 10:57
Steve London wrote :

> ENOUGH !
> 
> Take your little squabble off-line !

Do you have anything to add?  Maybe your opinion could make a difference?  

I think this topic is important enough to warrant discussion.  I would like
to understand where k1ttt is coming from other than the status-quo and it is
to much work.
//
//----------------------------------------------------------------------
//
N4ZR 2005-11-14 12:03
Pat Collins N8VW wrote:
>...
>Then what is this list for?  So we can all just nod our heads in argreement
>with the first idea that comes around with out ...
...snip...
>... will be marked as non-verified, untrusted data and the users will be able to
>filter those out.  How is that not agreeing?

Pat, for those of us who aren't technical, let's assume you have a process where
a user registers, receives and installs some sort of a key that thereafter identifies
his score data as being his. Hypothetically, that's a once-only burden, right?
But then he must ensure that he retains that key, right?  If his hard drive fails,
he has to restore it from somewhere?  What if he installs a new version of the software
he has been using or switches logging software altogether?  What about the logging
software writers who must accommodate not only providing the data in the right format,
but also integrating a key?

And for what?  Contest sponsors have been using robots for close to a decade, but there
has not been a single instance of someone tampering with another's score submission,
even though it would be trivially easy to do so; the same goes for the 3830 claimed-score
process.  As I also pointed out before. the damage that would be done, even if a first-ever
contest-score spoofing did take place, would be trivial.

If the extra hassle reduces potential participation in a system by even 1 percent, that's
1 percent too much.
//
//----------------------------------------------------------------------
//
N8VW 2005-11-14 13:13
Pete Smith wrote :
> Pat, for those of us who aren't technical, let's assume you have a process
where a user registers, receives and installs some sort of a key that
thereafter identifies his score data as being his. Hypothetically, that's a
once-only burden, right?  But then he must ensure that he retains that key,
right?  If his hard drive fails, he has to restore it from somewhere?  What
if he installs a new version of the software he has been using or switches
logging software altogether?  What about the logging software writers who
must accommodate not only providing the data in the right format, but also
integrating a key?

>

Here is how it would work.  Computer software would generate unique key for
use during duration of contest period for posting score.  The scoreboard
system would take that key + the callsign and some salt and generate a
unique hash that would be returned from the initial post and would be used
from then on to post.  Note that the user has to do nothing.  If someone
tries to post using that persons call during the contest period they won't
have the unique key and won't be able to recreate the returned hash.  This
hash would be deleted after the contest when I assume posting would stop
anyway.  Next contest rinse, repeat.  

Note that this doesn't prevent someone from grabbing a callsign, but it does
prevent someone from spoofing are modifying someones score during the
contest.  To really prevent spoofing somekind of registration system is
really required.

Here is an example using xml-rpc.  The method is score.authenticate.


>>> sb = xmlrpclib.Server("http://scoreboard.oqp.us/xmlrpc.php")
>>> pprint(sb.system.methodHelp('score.authenticate'))

'Returns a key for posting.  This token will be tied to your callsign for
the length of the contest. Requires a callsign and a unique key.'

>>> pprint(sb.score.authenticate('n8vw','my key'))

'7ec8f73363a8aa3aa23973a704042c48'

>>> pprint(sb.score.authenticate('n8vw','what is my key'))

'3bac8b438e9434bff01e0770bb304737'

>>> pprint(sb.score.authenticate('n8vw','my key'))        

'7ec8f73363a8aa3aa23973a704042c48'

> And for what?  Contest sponsors have been using robots for close to a
decade, but there has not been a single instance of someone tampering with
another's score submission, even though it would be trivially easy to do so;
the same goes for the 3830 claimed-score process.  As I also pointed out
before. the damage that would be done, even if a first-ever contest-score
spoofing did take place, would be trivial.

> 

How do you know this hasn't happened.  Most of the sponsers are pretty hush
hush about things like this.

> If the extra hassle reduces potential participation in a system by even 1
percent, that's 1 percent too much.

> 

You know someone will complain about something. :)
//
//----------------------------------------------------------------------
//
WA7BNM 2005-11-14 20:31
I think there's been a lot of good discussion on the authentication/security issue,
but I think we've reached the point that we need to table the issue for the moment.
In order to publish another version of the DTD (not the last version), let's see what
we can agree on.

For starters from the original proposed changes, can we agree to the following:

1. The new element and attribute names.

2. Addition of the web link element as a zero or once element.

3. Addition of the comments element as a zero or once element.

4. Addition of the operating time element as a zero or once element.

5. Designations of bands by frequency: 1.8, 3.5, 7, 14, 21, 28, 50, 144, 222, 432,
903, 1.2, 2.3, etc., rather than wavelength. (I'm particularly interested in hearing
from logging software publishers about this one.)

6. Addition of an e-mail element as a zero or once element.

7. Addition of continent to list of QTH elements.

Please indicate your agreement/disagreement with each item in this list, or proposed
alternative. These seem to be the least controversial. We'll make a pass at reaching
agreement on some others once we've dealt with these. Thanks.
//
//----------------------------------------------------------------------
//
WB0WAO 2005-11-14 22:12
>For starters from the original proposed changes, can we agree to the following:

>1. The new element and attribute names.

Agreed, with the exception of the following:

a) Suggest "countryprimarysubdivision" instead of "countrysubdivision" or "stprvoth"
b) Suggest "countrysecondarysubdivision" instead of "countrysubsubdivision" or "county"

>2. Addition of the web link element as a zero or once element.

Agreed.

>3. Addition of the comments element as a zero or once element.

Agreed - Has any thought been given to the max length of this element?

>4. Addition of the operating time element as a zero or once element.

Agreed

>5. Designations of bands by frequency: 1.8, 3.5, 7, 14, 21, 28, 50, 144, 222, 432, 903, 1.2,
 2.3, etc., rather than wavelength. (I'm particularly interested in hearing from logging
 software publishers about this one.)

Agreed

>6. Addition of an e-mail element as a zero or once element.

Agreed

>7. Addition of continent to list of QTH elements.

Agreed
//
//----------------------------------------------------------------------
//
WA7BNM 2005-11-14 23:12
Dennis Ponsness wrote:
>>1. The new element and attribute names.

>Agreed, with the exception of the following:

>a) Suggest "countryprimarysubdivision" instead of "countrysubdivision" or "stprvoth"
>b) Suggest "countrysecondarysubdivision" instead of "countrysubsubdivision" or "county"

I think your suggestion is certainly worthy of consideration, but I was saving the
discussion of the proposed modification of specifying geographic hierarchy for the
next phase of discussion/agreement. We can agree on the associated element names then.