Subject: [domainrep] Discussion items for Repute session at Taipei

From: Dave CROCKER <[email-masked]>
Date: Mon, 10 Oct 2011 18:10:42 -0700

Folks,

Howdy.

It looks as if we will have a one-hour session in Taipei.  We're trying to 
assemble and agenda.

Are there specific items you would like to see discussed, especially items of 
some disagreement that might be able to make some progress?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 13 Oct 2011 15:24:38 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Monday, October 10, 2011 6:11 PM
> To: [email-masked]
> Subject: [domainrep] Discussion items for Repute session at Taipei
> 

In general, a review of the established charter and the documents we have (and who's editing them) would be good to set the stage and start getting work done.  I think our current documents cover most of the pre-BoF topics, but not necessarily some of the concerns that were brought up during the BoF.  Beginning to track those would be a good idea to make sure they don't get lost.

There are two discussions we might consider having in person, time permitting, just to get our debate and decisions about them on the record:

1) XML vs. JSON; the drafts currently use XML, but JSON is the new hotness especially for small objects, which nicely describes the reputon.  My own preference is for XML because the availability of mature parsing code is more widespread than it is for JSON, but that view could be myopic.

2) DNS vs. a new UDP thing: We have stub drafts for both.  It's hardly a new argument.

By the time of Taipei, I will have a sample implementation based on our current drafts and will have some implementation and operational anecdotes to share.  In particular, I made one change to the long-form query, adding an "updated" field that indicates as of what timestamp the reported reputation was considered "current"; a new draft has been uploaded already reflecting this.

Also, Mark Nottingham pointed me at http://tools.ietf.org/html/draft-gregorio-uritemplate-07, a proposed method for describing to an application how to construct a URI for doing queries.  The template for REPUTE could be stored in the DNS in a predictable TXT record or some other discovery method with a default specified in our draft; the REPUTE client retrieves this and then uses it, or the default, to construct the actual REPUTE query.  It looks good to me, especially as I am in the midst of implementing a sample server and have run into a difficulty in this area.  I'll also have that to talk about by the time of Taipei.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 13 Oct 2011 15:52:33 -0700

On 10/13/2011 3:24 PM, Murray S. Kucherawy wrote:
> There are two discussions we might consider having in person, time
> permitting, just to get our debate and decisions about them on the record:
>
> 1) XML vs. JSON; the drafts currently use XML, but JSON is the new hotness
> especially for small objects, which nicely describes the reputon.  My own
> preference is for XML because the availability of mature parsing code is more
> widespread than it is for JSON, but that view could be myopic.
>

Because face2face time at IETF meetings is so scarce, the long-standing and very 
strong preference in the IETF is to focus on "issues" rather than "review" or 
"tutorial".  As such, the "time permitting" should apply to the review more than 
to these 2 isues.  In other words, swap the prioritization.

However since it doesn't make sense to have the review come second, I think it's
a matter of biasing the time allocation towards discussion of these two issues,
at the expense of the introductory material.

Happily, as you note, these are topic with well-understood underlying details.
Their resolution is more a matter of exploring preferences than in understanding
differences.  Still, any discussion takes time.  I'll

> Also, Mark Nottingham pointed me at
> http://tools.ietf.org/html/draft-gregorio-uritemplate-07, a proposed method
> for describing to an application how to construct a URI for doing queries.
> The template for REPUTE ...

I assume that this would be a way of having a service declare what attributes it 
supports having queried?  Does that need anything as lofty as a URI or as 
complex as this proposal permits?

And with that latter question, I think I'm demonstrating that this is likely a 
fuzzier (ie, more interesting) topic.

My own reaction is to suggest that we allocate 45 minutes for these 3 items, 
trying to keep the first two to about 10 minutes each.

And, yes, that means 15 minutes total for "hello and this is the set of 
documents we are working on and this is what they cover".

I'll suggest leaving the implementation report to the end, if there is time.

That's a proposal for revising the proposed agenda.

Reactions?

d/

-- 

   Dave Crocker

---

From: "David F. Skoll" <[email-masked]>
Date: Thu, 13 Oct 2011 22:03:14 -0400

On Thu, 13 Oct 2011 15:24:38 -0700
"Murray S. Kucherawy" <[email-masked]> wrote:

> 1) XML vs. JSON; the drafts currently use XML, but JSON is the new
> hotness especially for small objects, which nicely describes the
> reputon.  My own preference is for XML because the availability of
> mature parsing code is more widespread than it is for JSON, but that
> view could be myopic.

+1 for ABX (Anything But XML) :)

I like JSON.  There are pretty good JSON parsers for most programming
languages.

My beef with XML is that it's ugly, hard for humans to read, and prone
to abuse (eg, people encoding bitfields in XML... ugh.)

Regards,

David.

---

From: "John Levine" <[email-masked]>
Date: 14 Oct 2011 02:24:36 -0000

>> reputon.

Unless there's some technical issue beyond the generic XML vs. JSON
ones, this doesn't sound like it would be particularly productive to
try and resolve this in Taipei.  Either could work, which might work
better depends on whether the only issue is defining a container
format (advantage JSON) or whether we turn out to be doing something
that the mountain of existing tools already does (advantage XML.)

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 17 Oct 2011 11:42:22 -0700

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Thursday, October 13, 2011 3:53 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [domainrep] Discussion items for Repute session at Taipei
> 

Both arguments are interesting but I'm prepared to accept consensus.  For the first question, I'm currently partial to XML but only because the parsing libraries are mature and supported, and that's what my sample implementation has used.  I also only did the heavyweight (XML) query and not the lightweight (DNS) one, so I have no skin in the game there yet.

> complex as this proposal permits?

Mark states that current practice on the web side of things is to support templates like this, so any given reputation service can announce how it wants clients to format queries rather than having a fixed URI format specified in an RFC to which both sides must conform.  What's missing (deliberately) from that draft is the mechanism by which a particular service's URI template is discovered, so our HTTP document would need to come up with something.  Off the top of my head, the best ideas are a DNS TXT query to a fixed name (e.g., for a reputation service based at "repute.example.com", do a TXT query to "_qt.repute.example.com" to ask for a template, falling back to something in the draft if none is found), or to do an HTTP query to a fixed URI relative to the reputation service looking for the template (again with a fallback to something documented).

> fuzzier (ie, more interesting) topic.

I'll aim to implement one or the other in time for Taipei and let that be fodder for discussion.

> I'll suggest leaving the implementation report to the end, if there is

Sounds good to me.

-MSK

---

From: Leif Johansson <[email-masked]>
Date: Tue, 18 Oct 2011 02:41:36 +0200

> to abuse (eg, people encoding bitfields in XML... ugh.)

A word of warning though - JSON gets really ugly if you have to do
namespace managment. Usually this winds up being an issue with
extensibility so if you can keep extensibility suitably "bottled up"
then JSON has a clear advantage in terms of readability.

	Cheers Leif

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 Oct 2011 19:08:17 -0700

> Both arguments are interesting but I'm prepared to accept consensus.  For the first question, I'm currently partial to XML but only because the parsing libraries are mature and supported, and that'…
Overhead is a significant concern affecting performance, where JSON 
(JavaScript Object Notation) wins over XML.  It uses name/value pairs 
and ordered value lists.   http://www.json.org/
Twitter now exclusively uses JSON, for example.  You'll find JSON 
language extensions for all computer languages for this lighter weight 
structuring.
> Mark states that current practice on the web side of things is to support templates like this, so any given reputation service can announce how it wants clients to format queries rather than having…
Please do not reinvent yet another discovery mechanism.  Use SRV records 
and conventions and not TXT records.  It seems email suffers from the 
NIH factor and has already invented a significant number of TXT record 
formats.  There are already many services and systems able to 
immediately use standard SRV conventions in an effective manner.
> I'll aim to implement one or the other in time for Taipei and let that be fodder for discussion.
Although I was in Taipei this time last year, I won't be able to make 
it, but I am sure others will take my place. :^)
>> I'll suggest leaving the implementation report to the end, if there is
The world has remained fairly litigious.  What has changed is that 
people have been trained that complaining is a waste and grow frustrated 
instead.  As a result, there is a shrinking percentage of these duffers 
left.  It seems setting aside some time to consider the merits of 
defending reputations through use of authentication as an expressed 
minimum requirement could provide benefits by changing the negative trends.

Neither SPF nor DKIM can properly defend domains.  This is not about 
semantics, it is about the differences between authorization, and 
signatures that omit senders and intended recipients against actually 
authenticating _accountable_ domains.  These two schemes largely support 
white-listing of domains considered "too big to block" and glaringly 
lack a practical means to defend smaller domains or at inhibiting spam.

It is interesting that services like twitter's ad revenue unique 
criteria gives them an incentive to quickly cancel abusive accounts.  
Two seconds later, they may reappear under a different name.  For email 
to compete with social networks, a light weight method to authenticate 
outbound MTAs is needed, or eventually email will be supplanted by 
various proprietary services.  Many domains are not aware of their 
incoming connection failures due to loads they don't see in SMTP logs.  
Incoming messages might not be blocked, but may never get through the noise.

In the face of IPv6, address authorizations schemes will become 
increasingly problematic and disruptive.  Email needs to take a lesson 
from social networks, where each develops their own "buddy" list as an 
overlay to what is maintained by individual users.

To: [email-masked]
From: [email-masked]

Please add this new service to your "buddy" list.

I understand failure to respond to your complaints in a timely manner 
may cause my domain to be removed from your "buddy" list.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 18 Oct 2011 12:57:06 +0200

On 18/Oct/11 04:08, Douglas Otis wrote:
> For email to compete with social networks, a light weight method to
> authenticate outbound MTAs is needed, or eventually email will be
> supplanted by various proprietary services.

That's already happening, albeit gradually.  What a shame to be unable
to preserve SMTP!

---

From: Chris Lewis <[email-masked]>
Date: Tue, 18 Oct 2011 19:37:15 -0400

On 11-10-13 06:52 PM, Dave CROCKER wrote:

 > My own reaction is to suggest that we allocate 45 minutes for these 3
 > items, trying to keep the first two to about 10 minutes each.
 >

This seems to be the best way.  Expend the valuable time on the stuff
that needs discussion and decision, the rest is more administrivia that
is more amenable to email if necessary.

I'd also suggest that in the first two sessions the time be expended in
a straightforward listing of pros and cons, and then a vote.  That way
you can more easily keep within the time constraints.  If you push the
expectation of 13 minutes worth of "let's exhaustively list the pros and 
cons, do a show of hands", it should go smoothly.

I wuz there when they voted between SSLv3 and whatever that was for TLS. 
_Months_ of fruitless wheel spinning ended in just a few minutes.

I don't have any useful familiarity with either XML or JSON.  I
personally tend towards JSON, because of simplicity and readability
while still being much more compact.  The overhead in JSON parsing (both 
in time and space) is bound to be considerably less than that of XML. 
It really doesn't look like JSON tools are lacking despite the
perception it being "new".

On the DNS vs. "other UDP" light weight.  From a pure
practicality/adoption standpoint, the existing DNSBL mechanism handles
surprisingly well what _most_ sites would contemplate (and often already 
are) using for the short and medium term - meaning manual discovery of 
policy&meaning&interpretation of resulting A records (via the issuer's 
service description (usually web site)).

Given that most usage now and for the short-medium term future is
adequately handled by DNSBL technology as it stands, anything else would 
have a pretty poor chance of achieving critical mass and success, even 
if it's "better" at the "fancier" end.

Reinventing the wheel seems a poor use of our time.

Putting an automatible discovery layer on top of what already exists
should be interesting enough, and go a long way towards making the more
sophisticated uses standardizable.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 23 Oct 2011 13:40:00 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Monday, October 17, 2011 11:42 AM
> To: [email-masked]
> Mark states that current practice on the web side of things is to
> support templates like this, so any given reputation service can
> announce how it wants clients to format queries rather than having a
> fixed URI format specified in an RFC to which both sides must conform.
> What's missing (deliberately) from that draft is the mechanism by which
> a particular service's URI template is discovered, so our HTTP document
> would need to come up with something.  Off the top of my head, the best
> ideas are a DNS TXT query to a fixed name (e.g., for a reputation
> service based at "repute.example.com", do a TXT query to
> "_qt.repute.example.com" to ask for a template, falling back to
> something in the draft if none is found), or to do an HTTP query to a
> fixed URI relative to the reputation service looking for the template
> (again with a fallback to something documented).

Mark further advises that the conventional solution to template discovery is a well-known URI, registered with IANA.  Version -02 of the "query-http" draft thus introduces this concept.  It also means if the template can't be downloaded, the query has to be aborted (i.e., applications typically don't define hard-coded default templates).

I've updated my implementation accordingly.  Seems to work nicely.

-MSK