Subject: [domainrep] WGLC: draft-ietf-repute-email-identifiers-04

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Nov 2012 16:32:44 -0500

This is a Working Group Last Call for:

    A Reputation Response Set for Email Identifiers

    draft-ietf-repute-email-identifiers-04

Please review these documents and bring any remaining issues to the
attention of the Working Group on this list.

The working group last call ends:

    November 23, 2012.

/d
Repute WG Chair

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

-- 
  Dave Crocker
  bbiw.net

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 13 Nov 2012 18:17:30 +0000

One comment: the list of assertions in section 3.1 doesn't include anything that could be used to describe behaviors like bullying, sending threats, etc. Would that type of assertion be useful? If so, suggested text:

THREATS: The subject identifier is associated with sending or handling email describing threatening behavior.

Scott

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 13 Nov 2012 18:21:59 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hollenbeck, Scott
> Sent: Tuesday, November 13, 2012 1:18 PM
> To: [email-masked]
> Subject: Re: [domainrep] WGLC: draft-ietf-repute-email-identifiers-04
> 
> One comment: the list of assertions in section 3.1 doesn't include
> anything that could be used to describe behaviors like bullying,
> sending threats, etc. Would that type of assertion be useful? If so,
> suggested text:
> 

Sorry, another comment: Section 6 of this document (Security Considerations) is still TBD.

Scott

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Nov 2012 10:59:55 -0800

Sorry, yes.  I'll get that updated shortly with a new version.

-MSK

On Tue, Nov 13, 2012 at 10:21 AM, Hollenbeck, Scott <
[email-masked]> wrote:

> _______________________________________________
> domainrep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/domainrep
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Nov 2012 17:44:50 -0800

Perhaps 'personally abusive'?  Some problematic mail is not exactly threatening.  E.g, sending lots of mail to you that criticizes everything you post or constantly calls you an asshole.

d/
--
Dave Crocker
bbiw.net

via mobile

-----Original Message-----
From: "Hollenbeck, Scott" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Tue, 13 Nov 2012 10:17 AM
Subject: Re: [domainrep] WGLC:  draft-ietf-repute-email-identifiers-04

Scott

---

From: Chris Lewis <[email-masked]>
Date: Tue, 13 Nov 2012 23:58:46 -0500

> Perhaps 'personally abusive'?  Some problematic mail is not exactly threatening.  E.g, sending lots of mail to you that criticizes everything you post or constantly calls you an asshole.

Better I think:

ABUSIVE: The subject identifier is associated with sending or handling
email of a personally abusive or otherwise harassing nature.

[The stereo-typical "love-sick stalker"'s emails aren't strictly
definable as "abusive" per-se in the sense of your phrase.  Harassment
most certainly.  I don't think "Harassive" is a word, and the spell
checker seems to agree ;-)]

I don't think you'd see that flag very often.  But for completeness...

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Nov 2012 22:30:45 -0800

I typed several messages arguing that we shouldn't do this, and then talked
myself out of sending each of them.  I think that means it's a reasonable
suggestion.

I do think it's useful to include threatening conduct as an example though,
so how about compromise text:

ABUSIVE: The subject identifier is associated with sending or handling
email of a personally abusive, threatening, or otherwise harassing nature.

?

On Tue, Nov 13, 2012 at 8:58 PM, Chris Lewis <[email-masked]>wrote:

> > Perhaps 'personally abusive'?  Some problematic mail is not exactly
> threatening.  E.g, sending lots of mail to you that criticizes everything
> you post or constantly calls you an asshole.
>
> Better I think:
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 Nov 2012 22:36:36 -0800

Wfm. 

d/
--
Dave Crocker
bbiw.net

via mobile

-----Original Message-----
From: "Murray S. Kucherawy" <[email-masked]>
To: Chris Lewis <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Tue, 13 Nov 2012 10:30 PM
Subject: Re: [domainrep] WGLC: draft-ietf-repute-email-identifiers-04

?

---

From: Chris Lewis <[email-masked]>
Date: Wed, 14 Nov 2012 01:43:54 -0500

On 12-11-14 01:30 AM, Murray S. Kucherawy wrote:
> I typed several messages arguing that we shouldn't do this, and then
> talked myself out of sending each of them.  I think that means it's a
> reasonable suggestion.
> 
> I do think it's useful to include threatening conduct as an example
> though, so how about compromise text:
> 

I'm good with that.  As long as we don't have to include 15 more
examples in that sentence ;-)

---

From: Peter Koch <[email-masked]>
Date: Wed, 14 Nov 2012 08:42:16 +0100

>    draft-ietf-repute-email-identifiers-04

I have read version -05 of the document.  I am neither voicing support
nor opposition, just note that the document tries to register a value with
IANA with reference to [I-D.REPUTE-MODEL], in which no IANA
registry is opened and no policy defined.

Also, case is used inconsistently for the tags in sections 3.1 and 4.1.

The registration template says "Evaluates DNS domain names found in email"
but some of the fields do not relate to domain names (rather IP addresses)
and the descriptive text suggests that the granularity is actually
at user level.

draft-ietf-repute-email-identifiers-05 aims at standards track, but has
a {correct} normative reference to Experimental RFC 4408.

-Peter

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 14 Nov 2012 11:57:34 +0000

Same here.

Scott

> Behalf Of Dave Crocker
> Sent: Wednesday, November 14, 2012 1:37 AM
> To: Murray S. Kucherawy; Chris Lewis
> Cc: [email-masked]
> > threatening.  E.g, sending lots of mail to you that criticizes
> > everything you post or constantly calls you an asshole.
> >
> > Better I think:
> >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Nov 2012 14:37:01 -0800

Quite right, the registry definition moved to the "media-type" document.
Updated in the working copy.

I had somehow reached the conclusion that key matching in JSON was
case-insensitive.  I've adjusted them all to be all-uppercase, though going
to all-lowercase would be fine too.  Please let me know if there's
convention or preference to be observed here.

I've updated the registration template to mention that IP addresses are
also covered by the application.  Which text are you talking about with
respect to user level application?

RFC4408 being Experimental isn't a problem now because (a) it's already in
the downref registry, and (b) there's a Proposed Standard coming out of the
spfbis working group, so we have the option of going either way.  I'd be
fine pointing at the impending PS and just waiting for it.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Nov 2012 16:26:04 -0800

Actually, now that I've implemented the all-uppercase change in code, I
hate it.  I think we should go to all-lowercase.  Unless there are
objections, I'll make that change in the next version of the draft.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 15 Nov 2012 12:07:05 +0000

Murray, I haven't been able to find anything that describes a requirement for either upper or lower case. The grammar in ECMA-262 allows both, so key matching is (as you noted) case-insensitive. FWIW Google's JSON style guide suggests "camel-cased, ascii strings". It's perfectly acceptable to adopt a lower-case convention and use it consistently.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, November 14, 2012 7:26 PM
To: Peter Koch
Cc: [email-masked]
Subject: Re: [domainrep] WGLC: draft-ietf-repute-email-identifiers-04

Actually, now that I've implemented the all-uppercase change in code, I hate it.  I think we should go to all-lowercase.  Unless there are objections, I'll make that change in the next version of the draft.

On Wed, Nov 14, 2012 at 2:37 PM, Murray S. Kucherawy <[email-masked]<mailto:[email-masked]>> wrote:
Quite right, the registry definition moved to the "media-type" document.  Updated in the working copy.

I had somehow reached the conclusion that key matching in JSON was case-insensitive.  I've adjusted them all to be all-uppercase, though going to all-lowercase would be fine too.  Please let me know if there's convention or preference to be observed here.

I've updated the registration template to mention that IP addresses are also covered by the application.  Which text are you talking about with respect to user level application?

RFC4408 being Experimental isn't a problem now because (a) it's already in the downref registry, and (b) there's a Proposed Standard coming out of the spfbis working group, so we have the option of going either way.  I'd be fine pointing at the impending PS and just waiting for it.

-MSK

On Tue, Nov 13, 2012 at 11:42 PM, Peter Koch <[email-masked]<mailto:[email-masked]>> wrote:

-Peter
_______________________________________________
domainrep mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/domainrep

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Nov 2012 10:41:31 -0800

Scott,

My own reading (RFC4627) is that the key in a JSON object is Unicode, but
it says nothing about case sensitivity.  Unless there are aspects of
Unicode I don't understand (quite possible), I imagine then it's up to the
application to decide (and specify) whether key searches within an object
are case-sensitive.

The working copies of our drafts all use lowercase now, so at least they're
consistent.  The question before us, then, is whether we need to say we
expect matching to be case-sensitive, since RFC4627 is (perhaps
deliberately) ambiguous.

-MSK

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 15 Nov 2012 18:47:37 +0000

In the absence of guidance to the contrary I think it's safe to pick a convention and document it. As noted earlier, I can't find anything in the references that addresses key case, either.

Scott

From: Murray S. Kucherawy [mailto:[email-masked]]
Sent: Thursday, November 15, 2012 1:42 PM
To: Hollenbeck, Scott
Cc: [email-masked]
Subject: Re: [domainrep] WGLC: draft-ietf-repute-email-identifiers-04

Scott,

My own reading (RFC4627) is that the key in a JSON object is Unicode, but it says nothing about case sensitivity.  Unless there are aspects of Unicode I don't understand (quite possible), I imagine then it's up to the application to decide (and specify) whether key searches within an object are case-sensitive.

The working copies of our drafts all use lowercase now, so at least they're consistent.  The question before us, then, is whether we need to say we expect matching to be case-sensitive, since RFC4627 is (perhaps deliberately) ambiguous.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 Nov 2012 10:48:28 -0800

imo case insensitivity is to be explicitly preferred always.  case sensitivity should apply only when unavoidable.
 
d/

  via mobile

---

From: "David F. Skoll" <[email-masked]>
Date: Thu, 15 Nov 2012 14:20:44 -0500

On Thu, 15 Nov 2012 10:41:31 -0800
"Murray S. Kucherawy" <[email-masked]> wrote:

> My own reading (RFC4627) is that the key in a JSON object is Unicode,
> but it says nothing about case sensitivity.

Well, here's one specification that uses JSON:
http://www.jsonrpc.org/specification

and it says: "All member names exchanged between the Client and the
Server that are considered for matching of any kind should be
considered to be case-sensitive."

> The question before us, then, is whether we need to say we expect
> matching to be case-sensitive, since RFC4627 is (perhaps
> deliberately) ambiguous.

I prefer case-sensitivity because it narrows the acceptable range
of inputs.

Regards,

David.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Nov 2012 11:25:23 -0800

There's a question of implementation, however. The JSON library I've been
using does its key matching using strcmp(), which is case sensitive.  I
presume that means JSON is inherently case sensitive.  I think that means
we don't need to say anything, because this is a property of JSON, not a
property of the use of JSON. But I also don't mind being explicit about it.

-MSK

On Thu, Nov 15, 2012 at 10:48 AM, Dave Crocker <[email-masked]> wrote:

>
> imo case insensitivity is to be explicitly preferred always.  case
> sensitivity should apply only when unavoidable.
>
>
> d/
>
> --
>   Dave Crocker

---

From: "David F. Skoll" <[email-masked]>
Date: Thu, 15 Nov 2012 14:34:04 -0500

On Thu, 15 Nov 2012 11:25:23 -0800
"Murray S. Kucherawy" <[email-masked]> wrote:

> There's a question of implementation, however. The JSON library I've
> been using does its key matching using strcmp(), which is case
> sensitive.  I presume that means JSON is inherently case sensitive.
> I think that means we don't need to say anything, because this is a
> property of JSON, not a property of the use of JSON. But I also don't
> mind being explicit about it.

I prefer explicitly say explicitly that it is case-sensitive.  Comparing UTF-8
strings case-sensitively is much easier, faster and less error-prone
than comparing them case-insensitively, especially once you use non-Latin
characters.  (I doubt that will be an issue for the reputation use-case,
but still...)

Regards,

David.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 15 Nov 2012 12:01:27 -0800

> I prefer case-sensitivity because it narrows the acceptable range

and it increases the source of human errors.

in any event:

    1. If we can document standard practice for json, then that's the 
practice we should use.

    2. Whatever the choice, it needs to be explicit in our docs.  Don't 
rely on assumptions about the infrastructure (json, or whatever.)

d/

-- 
  Dave Crocker
  bbiw.net