Re: draft-ietf-usefor-usepro-02

[Seth Breidbart <sethb@xxxxxxxxx>]

John Stanley <stanley@xxxxxxxx> wrote:
> Seth Breidbart <sethb@xxxxxxxxx>:

>>No, the implication is that the agent can _sometimes_ tell that an
>>email address is (known to be) valid, and sometimes cannot tell.
>
> Were that as far as it goes, fine. It isn't. The next step is the 
> pretense. "You may not use this address".

It's not a pretense, and it's saying "I won't let you use this address
_now_."

>>An unverified email address is one that has not been verified.  It
>>might not be verified because it's bogus, or it might not be verified
>>because nobody got around to verifying it.
>
> This statement demonstrates the farce. It might not be verified
> because it is impossible to verify.

It's certainly a reasonable policy to say "If you can't verify it to
me, then I won't let you use it."  Consider a bank; I walk in and ask
for some money from Seth Breidbart's account.  If I can verify to
their satisfaction that I am the Seth Breidbart who owns the account,
they let me have the money, else they don't.

Isn't that the policy google groups uses?

> The ISP through which I post has no idea what other domains I own,
> much less have access to email through, and in the domains I own, I
> can create addresses at whim. They have no way of verifying any of
> them.

They could send you a token and ask you to prove you received it.

> But we'll tell them they can pretend to know which 
> ones are invalid.

No, what they know is which ones they know to be valid, and which ones
they don't know to be valid.  Not knowing that something is valid is
not the same as knowing that it isn't valid.

Do you know that I am wearing shoes right now?  Do you know that I'm
not?  Would you stake your reputation on either one being true?

>>No, it is saying "I do not know this to be valid so _I_ won't let you
>>use it."
>
> Thus the pretense. If it cannot make the determination, it should do 
> nothing different. 

Nothing different from what?

It _can_ make the determination "You have not demonstrated to me that
you own the account you wish to post as."

>>> B. Not if we are going to tell users that they may use .invalid.
>>"MAY" means it's a matter of local policy.
> MAY is a permissive word meaning they are permitted to do something. If 
> they are not permitted to do something, then we are wrong.

MAY means the _site_ is permitted to do something.  It implies that
the site is permitted not to do it.  The users are subject to the
policy of the site.

>>The probability that it _will have been_ crossposted to is unity.  The
>>probability that it _will be_ crossposted to is less than unity.
>
> The draft makes no such fine distinction in tenses. "Likely to be 
> crossposted to" is open-ended. Even so, given the instructions we provide 
> for followup agents, and observed conditions on the net, a group that HAS
> BEEN crossposted to is very likely to be crossposted to again. Not just 
> "likely", VERY likely.

So you claim; but I can show examples otherwise.

>>No, it doesn't.  Crossposting to a group whose name was clearly
>>generated by a cat walking on the keyboard is not likely to be
>>repeated.
>
> Read USENET for awhile and see if actual practice doesn't contradict you.

Cats walking across keyboards is the best explanation for a lot of
Usenet that I've seen.

(It's too hard to train monkeys to type.)

>>Are you likely to graduate from high school?
> Since I have already, the answer is yes, I am very likely to graduate. It 
> is a certainty.

Not in the language I speak.

>>> SHOULD does not suffice. Regular people will see the RECOMMENDATION 
>>> synonym for SHOULD and configure their servers to reject .invalid 
>>> addresses, even though we explicitely tell people they MAY use them.
>>No, we tell sites they MAY accept them.
>
> We ought to tell them MUST, since we also tell users they MAY use them.

Sites don't MUST accept _anything_.  Are you saying that spammers
using .invalid should get a free pass?

>>What is the global harm if a site requires posts to have verifiable
>>local addresses?
>
> What is the global harm saying they must accept the standard way of 
> denoting an invalid address?

Preventing them from doing what they want which doesn't harm anyone
else.

>>"Here's the authorized way of doing this.  Sites will adopt their own
>>policies, which may be weaker or stronger."
>
> "Here's the standard way of doing things, but it might not be standard
> where you are because we didn't actually make it part of the requirements 
> for the standard." Foof.

"Here's the standard way of doing things.  Some sites don't allow you
to do that despite it being the standard way of doing it at sites that
do allow it."

Or would you claim that sites are required to allow crossposts to 9
newsgroups because that's the "standard way" to have a posting show up
in those 9 newsgroups?

> Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx>:

>>Yes, that was the idea, and as a consequence TLD .invalid did
>>not work on this server.  And what you've written in the draft
>>addresses it perfectly.
>
> Let's see. My ISP goes anal and tells me "you must use a valid and working
> email address in your postings." (Forget for the moment that THEY are
> inserting a non-working address in my articles for me at the present time.
> Forget for the moment that they are also outsourcing news to another
> company.) Ok. We'll even assume that they have some magic method of
> determining whether or not an "@peak.org" address is valid and working.  
. . .
> So, I use an address from one of my other domains. They say "no". And yet
> I'm using a valid and working address. I'm following the stated rule, and 
> yet, I am not permitted to post. Why is that?

Because your interpretation of the rule they stated isn't the same as
their interpretation of it.

Seth