Subject: [domainrep] At long last, some drafts and a charter

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Jun 2011 21:53:32 -0700

Greetings,

Although there hasn't been much activity on this list in several months, the ideas have certainly not died.  Back then, Nathaniel Borenstein posted a vision about a flexible reputation system might look like, and I've managed to convert his idea into a suite of drafts that lay out a general framework, some IANA work, and then a couple of example applications that use the framework.  I've also included a mechanism for query and response using DNS and HTTP, and left a blank one open as well for a UDP method in case there's resistance to doing a DNS-based application.

I have a potential platform for doing both server-side and client-side sample implementations of such work, though it'll be a bit longer before they're visible, and I'd like to use these drafts as a basis for doing so which is why it's important to get the community discussing this stuff once again.

I've attached the last version of the draft charter for a working group to work on a general reputation framework using these drafts as a basis, and requested a BoF in Quebec City based on the previous momentum and these drafts.  I'm hoping the enthusiasm for the idea isn't as dead as the list has been.

Please have a look at the drafts and this charter and provide commentary.  I'd love to see some momentum here in time for Quebec City and possibly other related meetings before then.

Thanks,
-MSK

---

From: "John Levine" <[email-masked]>
Date: 2 Jun 2011 05:27:15 -0000

>Please have a look at the drafts and this charter and provide
>commentary.  I'd love to see some momentum here in time for Quebec
>City and possibly other related meetings before then.

Hmmn.  Incorporating by reference my comments from last time, I'm still
trying to wrap my head around what this would be useful for.

One initial question: all of the sample assertions are bad, e.g.
IS-MALWARE or SENDS-SPAM.  I'd think it'd be at least as useful for
a credible third party to publish good or at least neutral assertions,
e.g. IS-A-TRANSATION (for a message) or IS-LAW-ENFORCEMENT (for a sender.)

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 1 Jun 2011 22:37:10 -0700

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Wednesday, June 01, 2011 10:27 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [domainrep] At long last, some drafts and a charter
> 

Several applications come to mind, but the most obvious ones from my perspective have to do with the correlation between some property of an object (a URL from a web page, an identity from a piece of email, whatever) and the likelihood it is associated with something good or bad (spam, malware, legit banks) based on past observed data.  Perhaps the simplest and most apparent of these is "this sender" (for some value of "sender") is typically associated with good (or bad) mail.  But it doesn't have to be a sender; it could be a URL or part of one from inside a message, or anything, because the framework is extensible.

> e.g. IS-A-TRANSATION (for a message) or IS-LAW-ENFORCEMENT (for a

The proposed system certainly allows positive assertions.  I just picked some common ones that are in use today paralleling what RBLs do in the IP space.

You had suggested using the NAICS codes, for example.  It seems to me a vocabulary about domain names, perhaps the identity one, could include that as an extension.

---

From: Nathaniel Borenstein <[email-masked]>
Date: Thu, 2 Jun 2011 07:32:48 -0400

> e.g. IS-A-TRANSATION (for a message) or IS-LAW-ENFORCEMENT (for a sender.)

I'm not sure what, precisely, you mean by "bad" in this context.  We all know that "spam" is a slippery concept, and that different parties will assess whether or not a message is spam differently.  But that doesn't make blacklists useless.  All such assertions are meaningful only as statements of the best judgment of the RATER.  Thus, a reputon doesn't assert that a sender or domain is absolutely a spammer.  It states that a certain rating authority believes it to be a spammer.  And I think this applies to some of your "neutral" assertions as well.  A repressive government and a human rights NGO might disagree strongly about whether or not the government's secret police should be considered law enforcement. -- Nathaniel

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Jun 2011 07:37:56 -0700

Ah yes, the drafts.  In all my excitement I forgot to post their various names.  They are:

A Model for Reputation Interchange
http://datatracker.ietf.org/doc/draft-kucherawy-reputation-model/

A Media Type for Reputation Interchange
http://datatracker.ietf.org/doc/draft-kucherawy-reputation-media-type/

Reputation Data Interchange using the DNS
http://datatracker.ietf.org/doc/draft-kucherawy-reputation-query-dns/

Reputation Data Interchange using HTTP and XML
http://datatracker.ietf.org/doc/draft-kucherawy-reputation-query-http/

Reputation Data Interchange using UDP
http://datatracker.ietf.org/doc/draft-kucherawy-reputation-query-udp/

A Reputation Vocabulary for Email Identities
http://datatracker.ietf.org/doc/draft-kucherawy-reputation-vocab-identity/

A Reputation Vocabulary for Email Properties
http://datatracker.ietf.org/doc/draft-kucherawy-reputation-vocab-email/

The UDP one is mostly empty, intended as a placeholder in case the DNS one gets too much negative feedback.  It can be dropped if that turns out not to be the case.

Ideally I'd like to have one more vocabulary definition for something that is not email centric.  I'll try to put one together someday soon if nobody else beats me to it.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
Sent: Wednesday, June 01, 2011 9:54 PM
To: [email-masked]
Subject: [domainrep] At long last, some drafts and a charter

Greetings,

Thanks,
-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 2 Jun 2011 10:50:39 -0400

> I'm not sure what, precisely, you mean by "bad" in this context.

Bad: Assertions that would make one less likely to accept mail, display a 
web page, or whatever.

I realize that you can construct hypothetical cases of spam traps that 
only want phishes, but I hope that's not what we're standardizing.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 02 Jun 2011 20:16:11 +0200

Hi Murray,

On 02/Jun/11 06:53, Murray S. Kucherawy wrote:
> commentary.

I've only skimmed the first draft.  There seems to be an ellipsis in
the argument, as developed in the reputation-model's introduction
about the paragraph saying

  The next step, which could usefully be undertaken only in the
  presence of such stronger identity mechanisms, is to establish a
  mechanism by which mutually trusted parties can exchange information
  about other parties.  Such information is known as reputation
  information.

That way, the text assumes the existence of "mutually trusted parties"
after describing a universe of parties that are merely mutually
identifiable.  The transition from identifying to trusting is not
clear, and may appear to be beyond the scope of the model, except that
the text is also saying that it is at its core.

IIRC, this is where discussion paused.  Just to recall what the point
was, let me mention we came here after abuse-reporting, wondering what
would result from weighting received vs. reported messages of a given
identity.  Forwarding abuse reports and exchanging those "reputation"
ratios seemed to be the building blocks for that collection, collation
and distillation that we won't discuss... Or does the fact that the
charter mentions a different mailing list imply that "domainrep"
remains available for discussing items that are specifically out of
scope for "repute"?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 2 Jun 2011 11:46:00 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alessandro Vesely
> Sent: Thursday, June 02, 2011 11:16 AM
> To: [email-masked]

It could be that the text needs improvement, but the point it's trying to make is that once you have a property of a message (for example) that is useful to evaluate, now you need a way to ask questions and get answers about the value of that property.  In the case of email, the DKIM allows the addition of an identifier to a message (in this case, a domain name) that can be verified rather than arbitrarily generated by the sender and blindly accepted by the receiver.  It's something meaningful that can be evaluated.  So that's where trust in the identity comes in.

The mutually trusted parties refer to the party that wishes to evaluate such a thing, and the party that has an opinion to express about it.  They need to trust each other, especially the client in that relationship which will presumably make a filtering decision based on what the server says.  By way of example, SSL secures a connection between two parties and possibly authenticates one or both of them, but makes no guarantee about the behavior of either within the connection.  That sort of establishment of trust is an out-of-band matter.

> remains available for discussing items that are specifically out of

I don't know the mechanics of the list name; there's been a generalization of the purpose of this work beyond simply domain names since that name was chosen, but I don't think it's guaranteed that the formation of a WG would involve creation of a new list.  We might just need to be careful not to get tunnel vision.

As for interchange of data among reputation providers, I believe we could address that if we feel that's something also in need of standardization and interoperability, but so far I suspect that's going to be largely a proprietary matter.  I could be wrong, though.

What I really want to avoid is codifying in an RFC the idea that one can only seek or provide reputation services about specific identities, or that one can only compute reputation based on specific properties of an object.  None of that belongs in a protocol specification, in my opinion.  If a reputation provider is foolish about how it collects or reports data, then the value of that service diminishes.  Those sorts of subjective things need to be out of scope.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 03 Jun 2011 13:23:59 +0200

On 02/Jun/11 20:46, Murray S. Kucherawy wrote:
>> From: On Behalf Of Alessandro Vesely
>> The transition from identifying to trusting is not clear, and may
>> appear to be beyond the scope of the model, except that the text
>> is also saying that it is at its core.
> 
> It could be that the text needs improvement, but the point it's
> trying to make is that once you have a property of a message (for
> example) that is useful to evaluate, now you need a way to ask
> questions and get answers about the value of that property.

The first item mentioned in the representation is "the identity of the
entity providing the reputation information".  How this may limit the
kinds of answers is not obvious.

> In the case of email, the DKIM allows the addition of an identifier
> to a message (in this case, a domain name) that can be verified
> rather than arbitrarily generated by the sender and blindly
> accepted by the receiver.  It's something meaningful that can be
> evaluated.  So that's where trust in the identity comes in.

Yes, but it assumes the client already trusts the information
provider.  How does /this/ come into being?

> The mutually trusted parties refer to the party that wishes to
> evaluate such a thing, and the party that has an opinion to express
> about it.  They need to trust each other, especially the client in
> that relationship which will presumably make a filtering decision
> based on what the server says.  By way of example, SSL secures a
> connection between two parties and possibly authenticates one or
> both of them, but makes no guarantee about the behavior of either
> within the connection.  That sort of establishment of trust is an
> out-of-band matter.

Exactly.  The question is, if clients already have an out-of-band
mechanism whereby they can trust information providers, why don't they
use such mechanism to evaluate message identities as well.
(This is similar to the requirement to exchange keys over a secure
channel, before public-key cryptography: if parties already have a
secure channel, what do they need cryptography for?)

Perhaps, we can assume that reputation providers will be limited to a
few well-known actors, such as Spamhaus, national CERTs, and the like,
while the identities to be evaluated vary widely and frequently.
However, this answer doesn't scale.  If I were a VBR provider I
wouldn't know where to bang my head.  Apparently, they can state
something for brilliantly-white prominent identities only.  How do I
learn the reputation of a small Chinese shop?  The vastness of the
gray area seems to be calling for many many more reputation providers,
possibly arranged in a suitable topology so that it's easier to
determine which ones are more knowledgeable for the identity at hand.

Even if these questions are not part of the protocol, they are part of
the real problem.  Maybe a reputation provider's identity is the
preeminent candidate for (recursive) reputation queries.  Maybe a
discovery mechanism is necessary.

> What I really want to avoid is codifying in an RFC the idea that
> one can only seek or provide reputation services about specific
> identities, or that one can only compute reputation based on
> specific properties of an object.  None of that belongs in a
> protocol specification, in my opinion.  If a reputation provider is
> foolish about how it collects or reports data, then the value of
> that service diminishes.  Those sorts of subjective things need to
> be out of scope.

Still, we stick on "reputation".  How is such kind of data different
from, say, addresses?  Why does it need a specific protocol?

I agree that generalization is useful and maybe the RFC had better be
at the abstraction level you propose, but working out from top to
bottom the DKIM+domain+email "example" is useful too.  That way we
could provide a sample implementation that actually computes real
data, however poorly collected, collated, and distilled.  Otherwise,
detaching abstraction from reality, we risk to talk nonsense, don't we?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Jun 2011 10:02:54 -0700

> Sent: Friday, June 03, 2011 4:24 AM
> To: [email-masked]

Does that need to be specified in the protocol?

How do you decide which RBLs to use (and trust), for example?

> use such mechanism to evaluate message identities as well.

To re-use the RBL analogy, you're saying: If I know which RBL providers I can trust, why can't I just figure out which IP addresses I want to talk to on my own?

> determine which ones are more knowledgeable for the identity at hand.

I don't see where in the documents that these limitations you're describing exist.  Assertions don't need to be purely positive; they can be anything.  Some of the proposals that have been floated include quality such as "sends-spam" or "sends-good-mail" which are definitely "good" and "bad" type things, but one could also assert "is-a-bank", "is-in-italy", etc.  VBR could also do these, but it's limited to Boolean expressions and nothing more detailed.

> discovery mechanism is necessary.

We don't have a discovery mechanism for RBLs now.  Do we need one?

> detaching abstraction from reality, we risk to talk nonsense, don't we?

That is exactly the approach this work is taking as one of its examples.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 03 Jun 2011 23:50:52 +0200

> Does that need to be specified in the protocol?

It would be nice if the protocol would support it, but in fact this is 
asking for a meta-reputation model, in which the reputation providers 
themselves also get a reputation. See also below.

> We don't have a discovery mechanism for RBLs now.  Do we need one?

A discovery mechanism is a separate issue from the reputation or expert 
area of reputation providers.

To follow the analogy of RBL's: over the years I regularly have to 
search through some recent mailing list archives to find out what 
people's opinion is on the quality of various RBL's/DNSBL's is. For 
DNSBL's http://www.sdsc.edu/~jeff/spam/cbc.html provides useful 
information about hits, but it doesn't provide information on the real 
quality of these lists. It appears that over time this type of lists 
have their own history: the quality of a DNSBL today is different from 
it's quality tomorrow and also different from that of yesterday.

Likewise, with a repuation system, a meta-reputation system certainly 
would have its value, but it will not be easy to make it successful. And 
I'm not sure it would have to fit into this framework. On the other 
hand, if the reputon is the smallest unit of reputation, a 
meta-reputation system would have to be built using these reputons as 
well...

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 3 Jun 2011 15:41:11 -0700

> From: Rolf E. Sonneveld [mailto:[email-masked]]
> Sent: Friday, June 03, 2011 2:51 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Yep, and you certainly could have a vocabulary that discusses the reputations of reputation servers, and that would probably be a useful application.  But I don't think the base protocol should specify, and certainly should not require, such a thing.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 04 Jun 2011 15:39:17 +0200

> We don't have a discovery mechanism for RBLs now.  Do we need one?

It wouldn't hurt.  But then a few RBLs can be enough to work with.
We already know how they work.  How about The Spamhaus Whitelist or
DNSWL.org?  I'll be grateful if someone reports some news about how
they are doing.

I may be wrong, but I have the impression that positive assertion are
more difficult to do.  The number of potential message streams is many
times the IPv4 address space.  The comparison with RBLs holds no
further.  For some kinds of assertions, one has to consider
abuse-reports and investigate a domain's reaction to receiving them.
How about assertions such as reacts-to-abuse-reports, has-personal-ids?

> That is exactly the approach this work is taking as one of its examples.

I'm happy with this statement of yours.  It'll be a very interesting
experience.  That way we'll gain enough insight to craft a protocol
that will work.  I look forward to participating to such experiment.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Jun 2011 23:12:52 -0700

> Sent: Saturday, June 04, 2011 6:39 AM
> To: [email-masked]

I'm still confused.  How would we write this into a protocol?

If you're talking about a reputation vocabulary for describing reputation services, the current framework does support such a thing.  Perhaps you could construct and propose one.  :-)

But that's not the same thing as a discovery mechanism, which means a system with no state can make a query someplace and find out where reputation services can be found.  RBLs have been plenty successful without such a mechanism so far.

> further.

Why would a positive assertion be any more difficult to do than a negative assertion?  Both involve collecting history about something and then doing some analysis work to form an opinion.  I don't think the protocol needs to change, though in either the positive or negative case the vocabulary must be carefully chosen.

> For some kinds of assertions, one has to consider

Sure, the current framework supports stuff like this as well.  Perhaps you'd like to try writing a vocabulary draft for this kind of thing?

-MSK

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 05 Jun 2011 13:07:52 +0200

> I'm still confused.  How would we write this into a protocol?

We may not write it at all.

> If you're talking about a reputation vocabulary for describing
> reputation services, the current framework does support such a
> thing.  Perhaps you could construct and propose one.  :-)

Yes, if I had experience with it I would.  I'm just saying that we
don't know.  You and Nathaniel have much more email experience than I,
thus your guesses are much better educated than mines, but we are
still guessing.  After we'll have been using the experimental example,
even if we build it using hacks that we'd never dare to write in an
RFC, we may be able to adjust our guesses and fine-tune the protocol.

Isn't that the plan you have in mind, more or less?  But implementing
such an example should be important enough to compare on the charter.

> But that's not the same thing as a discovery mechanism, which means
> a system with no state can make a query someplace and find out
> where reputation services can be found.  RBLs have been plenty
> successful without such a mechanism so far.

Discovery is one such guess, based on the huge number of reputation
providers that would be required for manually inspecting each domain's
practices --see below.

> Why would a positive assertion be any more difficult to do than a
> negative assertion?  Both involve collecting history about
> something and then doing some analysis work to form an opinion.

IME, there are many more black lists than white ones, and while some
BLs are used to make final decisions, e.g. rejecting a message, WLs
only contribute to a message's score.  (I recall discussing software
changes needed for whitelisting just some months ago, and they're not
yet implemented in the particular MTA I use.)  I conclude that the
difficulty gap must be relevant.

> I don't think the protocol needs to change, though in either the
> positive or negative case the vocabulary must be carefully chosen.

You may well be right...

>> For some kinds of assertions, one has to consider abuse-reports
>> and investigate a domain's reaction to receiving them. How about
>> assertions such as reacts-to-abuse-reports, has-personal-ids?
> 
> Sure, the current framework supports stuff like this as well.
> Perhaps you'd like to try writing a vocabulary draft for this kind
> of thing?

They are two other guesses.  I have a rough idea on how to evaluate
the first one, hinged on banning users from sending as a reaction to
abuse reports.  No idea for the second one, except manually trying to
get an account at the relevant domain --see above.  Even assuming such
assertions would be undoubtedly useful, they are useless if they
cannot be computed and retrieved.  Thus, I would not write them in an
RFC, at this stage, because useless vocabulary entries would diminish
the overall value of the protocol.

---

From: "John Levine" <[email-masked]>
Date: 5 Jun 2011 14:41:34 -0000

>negative assertion?  Both involve collecting history about something and
>then doing some analysis work to form an opinion.  I don't think the
>protocol needs to change, though in either the positive or negative case
>the vocabulary must be carefully chosen.

A significant hole I see is assertions that are not inherently good
nor bad but have a value beyond than yes and no.  I suspect that people
would be happier with a ZIP-CODE field with a five digit value rather
than 100,000 assertions like IS-ZIP-90210.  I am not sure about the
relative utility of assertions with controlled value ranges (postal
codes, states, NAICS codes) and assertions without (mailing address.)

R's,
John

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 09 Jun 2011 09:53:48 +0200

On 6/2/11 6:53 AM, Murray S. Kucherawy wrote:
>
> Greetings,
>
> Although there hasn't been much activity on this list in several 
> months, the ideas have certainly not died.  Back then, Nathaniel 
> Borenstein posted a vision about a flexible reputation system might 
> look like, and I've managed to convert his idea into a suite of drafts 
> that lay out a general framework, some IANA work, and then a couple of 
> example applications that use the framework.  I've also included a 
> mechanism for query and response using DNS and HTTP, and left a blank 
> one open as well for a UDP method in case there's resistance to doing 
> a DNS-based application.
>
> I have a potential platform for doing both server-side and client-side 
> sample implementations of such work, though it'll be a bit longer 
> before they're visible, and I'd like to use these drafts as a basis 
> for doing so which is why it's important to get the community 
> discussing this stuff once again.
>
> I've attached the last version of the draft charter for a working 
> group to work on a general reputation framework using these drafts as 
> a basis, and requested a BoF in Quebec City based on the previous 
> momentum and these drafts.  I'm hoping the enthusiasm for the idea 
> isn't as dead as the list has been.
>

although I will not be able to attend Quebec City, except via jabber, I 
very much welcome the creation of a working group for reputation! I'd be 
glad to help edit one or more of the documents and participate in 
experiments that can aid in the development of the protocols and 
specifications.

/rolf

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 17 Jun 2011 13:24:50 -0600

I'm interested in this Working Group, though my participation will be limited to the mailing list.

On Jun 2, 2011, at 12:53 AM, Murray S. Kucherawy wrote:

Greetings,

Although there hasn’t been much activity on this list in several months, the ideas have certainly not died.  Back then, Nathaniel Borenstein posted a vision about a flexible reputation system might look like, and I’ve managed to convert his idea into a suite of drafts that lay out a general framework, some IANA work, and then a couple of example applications that use the framework.  I’ve also included a mechanism for query and response using DNS and HTTP, and left a blank one open as well for a UDP method in case there’s resistance to doing a DNS-based application.

I have a potential platform for doing both server-side and client-side sample implementations of such work, though it’ll be a bit longer before they’re visible, and I’d like to use these drafts as a basis for doing so which is why it’s important to get the community discussing this stuff once again.

I’ve attached the last version of the draft charter for a working group to work on a general reputation framework using these drafts as a basis, and requested a BoF in Quebec City based on the previous momentum and these drafts.  I’m hoping the enthusiasm for the idea isn’t as dead as the list has been.

Please have a look at the drafts and this charter and provide commentary.  I’d love to see some momentum here in time for Quebec City and possibly other related meetings before then.

Thanks,
-MSK
<repute-charter>_______________________________________________
domainrep mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/domainrep

---

From: "J.D. Falk" <[email-masked]>
Date: Thu, 23 Jun 2011 12:56:03 -0700

Sorry I've been silent on this of late.  It's very good to see the progress (which I've been following carefully, if quietly), and I'm looking forward to a BoF in Quebec.

My employer, Return Path, will be interested in implementing once something implementable is drafted.

Can I get a +1 from other lurkers?

On Jun 1, 2011, at 9:53 PM, Murray S. Kucherawy wrote:

> [email-masked]

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Michael Adkins <[email-masked]>
Date: Thu, 23 Jun 2011 20:22:09 +0000

+1

On 6/23/11 12:56 PM, "J.D. Falk" <[email-masked]> wrote:

>Sorry I've been silent on this of late.  It's very good to see the
>progress (which I've been following carefully, if quietly), and I'm
>looking forward to a BoF in Quebec.
>
>> Although there hasn¹t been much activity on this list in several
>>Borenstein posted a vision about a flexible reputation system might look
>>like, and I¹ve managed to convert his idea into a suite of drafts that
>>lay out a general framework, some IANA work, and then a couple of
>>example applications that use the framework.  I¹ve also included a
>>one open as well for a UDP method in case there¹s resistance to doing a
>>DNS-based application.
>>  
>>sample implementations of such work, though it¹ll be a bit longer before
>>they¹re visible, and I¹d like to use these drafts as a basis for doing
>>so which is why it¹s important to get the community discussing this
>>stuff once again.
>>  
>> I¹ve attached the last version of the draft charter for a working group
>>to work on a general reputation framework using these drafts as a basis,
>>and requested a BoF in Quebec City based on the previous momentum and
>>these drafts.  I¹m hoping the enthusiasm for the idea isn¹t as dead as
>>the list has been.
>>  
>>commentary.  I¹d love to see some momentum here in time for Quebec City
>>and possibly other related meetings before then.
>>  
>> Thanks,
>> -MSK
>_______________________________________________
>domainrep mailing list
>[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2011 20:29:09 -0000

>Can I get a +1 from other lurkers?

I still have my doubts about how useful it will be, but it's certainly
worth a try.  I'll be in Quebec.

R's,
John

---

From: <[email-masked]>
Date: Thu, 23 Jun 2011 15:46:13 -0500

Just as a note on DNS, be aware that there are some DNS hosts (I won't name names, but you should fix your stuff if you know who you are) which will lowercase a dns query, so if you're doing a dns-based lookup which requires case sensitivity then there will be issues depending on who is the dns provider.

--adam

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Michael Adkins
> Sent: Thursday, June 23, 2011 4:22 PM
> To: J.D. Falk; [email-masked]
> look

---

From: "John Levine" <[email-masked]>
Date: 23 Jun 2011 22:00:34 -0000

>Just as a note on DNS, be aware that there are some DNS hosts (I
>won't name names, but you should fix your stuff if you know who you
>are) which will lowercase a dns query, so if you're doing a dns-based
>lookup which requires case sensitivity then there will be issues
>depending on who is the dns provider.

If you're doing a DNS-based lookup which requires case sensitivity,
your application is pretty badly broken.  RFC 1034 said in 1987 that
upper and lower case ASCII characters are equivalent in DNS names, and
that hasn't changed.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 23 Jun 2011 18:31:58 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of J.D. Falk
> Sent: Thursday, June 23, 2011 12:56 PM
> To: [email-masked]

+1 here, representing both a commercial interest and an open source one.  The commercial one will involve developers other than me, so it's really going to be two similar-but-different implementations.

And (obviously) I'll be putting time into documents.

-MSK

---

From: "Fred F. Tabsharani" <[email-masked]>
Date: Thu, 23 Jun 2011 13:30:52 -0700

+1

Fred Tabsharani
port25 Solutions, Inc
Vice President, Marketing
O: 510.526.3733 M: 510.367.5832
T: @tabsharani

> Sent: Thursday, June 23, 2011 1:22 PM
> >>look like, and I¹ve managed to convert his idea into a suite of drafts
> >>one open as well for a UDP method in case there¹s resistance to doing
> >>a DNS-based application.
> >>
> >> I have a potential platform for doing both server-side and
> >>client-side sample implementations of such work, though it¹ll be a bit
> >>longer before they¹re visible, and I¹d like to use these drafts as a
> >>basis for doing so which is why it¹s important to get the community
> >> I¹ve attached the last version of the draft charter for a working
> >>momentum and these drafts.  I¹m hoping the enthusiasm for the idea
> >>isn¹t as dead as the list has been.
> >>
> >>commentary.  I¹d love to see some momentum here in time for Quebec

---

From: Dennis Dayman <[email-masked]>
Date: Fri, 24 Jun 2011 09:46:08 +0100

+1

-Dennis

---

From: <[email-masked]>
Date: Fri, 24 Jun 2011 10:45:32 -0500

> upper and lower case ASCII characters are equivalent in DNS names, and

We're not, we've moved long past that, but the lack of case sensitivity in DNS reduces the amount of uniqueness that you can fit into a single query, which should be a concern.  If this issue has already been raised then I apologize for bringing it up.  See rfc4343 for additional clarification regarding the handling of case. 

--adam

---

From: "McDowell, Brett" <[email-masked]>
Date: Fri, 24 Jun 2011 09:52:43 -0600

This is redundant to my previous statement on the list, but maybe it's useful to have one thread where we collect all the interest in moving this effort forward... +1

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 24 Jun 2011 12:18:00 -0400

On Fri, Jun 24, 2011 at 10:45:32AM -0500, [email-masked] wrote:
> We're not, we've moved long past that, but the lack of case
> sensitivity in DNS reduces the amount of uniqueness that you can fit
> into a single query, which should be a concern.  If this issue has
> already been raised then I apologize for bringing it up.  See
> rfc4343 for additional clarification regarding the handling of case.

Careful here.

First, RFCs 1034 and 1035 do not say exactly that upper and lower case
ASCII characters are equivalent.  DNS is supposed to be
case-preserving but case-insensitive.  (In my humble opinion, this is
one of the most broken parts of the DNS, but never mind that.)

Second, because of label compression, you have no guarantees of the
case you're going to get back anyway.  The following labels all match
one another: eXaMpLe, example, EXAMPLE.  But label compression in many
implementations will store a pointer to the first instance of the
label, which can mean that while you get one value back, it might not
be the one you expect; and the case-preservation isn't quite what you
might expect it to be, because caches are going to get a
compressed label to store.

In at least one case I observed, the label compression included a
pointer back to the label in the (echoed) question section in the
response.  This meant that the labels you saw (for compressible
RRTYPEs) were exactly the ones you sent.  AFAIK this is changed, and I
don't know of any shipping systems that do it this way, but I'm not
actually sure it was wrong under the protocol anyway.

There has been a suggestion to use case sensitivity as a kind of extra
security measure:
http://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00.  This was
controversial, but at least one vendor has code shipping that does
this.

Finally, I guess it goes without saying that we're taking about (in
IDNA-speak) A-labels and not U-labels.  The latter aren't allowed to
have upper case characters, period.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Sat, 25 Jun 2011 10:34:41 +0200

+1

/rolf

---

From: SM <[email-masked]>
Date: Sun, 26 Jun 2011 01:38:07 -0700

Hi Murray,
>Ah yes, the drafts.  In all my excitement I forgot to post their 

I'll comment after I have read all the I-Ds.  I'm interested in the 
open source implementation of the specifications.

I'll likely follow the BoF over XMPP.

Regards,
-sm

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Jun 2011 16:04:33 -0400

Dear colleagues,

I thought it might be important to note for the record that I find
this work interesting and important.  I looked at the proposed
charter, and I think it's reasonable.  I also think the drafts are a
good start.  I hereby commit in public to doing reviews (and encourage
the authors, therefore, to poke me when I fail to make good on this).

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Jun 2011 11:07:46 -0700

> have upper case characters, period.
This restriction applies to IDNA-conforming applications such as SMTP or 
HTTP.  DNS itself doesn't care.  Its hard to say what limits a registrar 
or the zone owner might impose on label use right?

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 28 Jun 2011 14:16:41 -0400

On Tue, Jun 28, 2011 at 11:07:46AM -0700, Douglas Otis wrote:
> This restriction applies to IDNA-conforming applications such as
> SMTP or HTTP.  DNS itself doesn't care.  Its hard to say what limits
> a registrar or the zone owner might impose on label use right?

U-labels are not allowed to have upper case characters, period, and
things in the DNS are by definition not U-labels, because U-labels get
converted to A-labels when they're put in the DNS.  The fact that you
could put UTF-8 directly into a label in your DNS server is
irrelevant: it's still not a U-label.  So, to be stricter, the
restriction doesn't apply to DNS because the way DNS works with IDNA
is using A-labels; U-labels are defined in an IDNA context.

If you are serving something that is not an A-label (and if it's an
A-label it's guaranteed not to convert to an upper-case U-label), then
of course IDNA has nothing to say abotu what your DNS policies are.

If you _are_ purporting to serve A-labels, then IDNA does indeed have
plenty to say about what limits (apart from your local policy) need to
be on what you register.  See section 4 of RFC 5891.  Note that many
of us think that the "A-label only" form in 4.2.1 is a bad idea.

A

-- 
Andrew Sullivan
[email-masked]