gmane.ietf.apps-discuss

Re: Looking to begin discussion about email and IPv6

Martijn Grooten — 2012-05-25T16:21:27

ipv6whitelist.eu uses a CAPTCHA to prevent automated mass-registration
of IPv6 MTAs.

I'm not a big fan of CAPTCHAs in general, but it in this case it should
prevent botnet spammers from registering all of their IPv6 addresses.
It doesn't stop them registering a handful of addresses and sending
lots of messages per address, but the list is only supposed to be a
first step: don't accept anything that isn't listed and run blacklists,
whitelists and reputation services on the small subset of listed
addresses. It sounds like a reasonable solution to me.

One potential issue is the question of who should run such lists. I
don't think we should want a situation where there are dozens of bigger
and smaller lists like this and where you'd have to register your
address with all of them, just because you don't know which lists
recipients are using.

Martijn.


________________________________

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

Re: The acct: scheme question

Michiel de Jong — 2012-05-25T11:46:00

Yes, that is what i meant and also what i think would make sense.

Re: The acct: scheme question

John Bradley — 2012-05-25T11:39:51

Also move acct: tp a different spec.  If it gets approved that's fine.  If people use an un-appoved scheme name as an identifier for computability with existing deployments that is fine as well, but it should not be in the WF spec.

I think Blane and I agree on the point that the server not the client is in the best position to figure out what the user intended if they type in user< at >foo.com.   The client is adding acct: to say that it doesn't know.  sending a relative URI as we do in SWD and letting the server figure it out is probably the best thing.

It is a parameter, I don't see any reason that a relative URI would not be valid, as long as a authority is present.

John B.


On 2012-05-25, at 7:06 AM, Michiel de Jong wrote:

Re: The acct: scheme question

Michiel de Jong — 2012-05-25T11:06:43

Indeed I think we can conclude:
- an acct: scheme would be helpful
- it does not currently exist
- we have to think about what to do until it exists

On Wed, May 16, 2012 at 4:34 PM, Blaine Cook <romeda< at >gmail.com> wrote:

And this was +1'ed by Mike Jones. So I pointed out that:


Once acct: is a URI scheme, you'll be able to say the parameter takes
"any URI". Until then, you'll have two options:

1) say the parameter takes "any URI or user< at >host"
2) say the parameter takes "any existing URI scheme or acct:user< at >host"

I think we agree that as Blaine said, there *should* be an URI, but I
think we also can agree that the limbo period would be too long to say
"let's first wait to see if acct: gets accepted, and then decide what
we do". So we have to make a choice about the period between now and
the 'verdict'. For that period, I would vote for option 1. I think
it's clear that option 1 has a down-side:
- it deviates from host-meta as such

but option 2 has three downsides:
- in relying on a scheme that does not

Re: Aggregated service discovery

Alessandro Vesely — 2012-05-25T08:15:15


Requiring authentication in order to discover the services would seem
to be a relevant functional difference w.r.t. SRV records.  I, for
one, don't use SRV records because of those two reasons.

Of course, directing all mass, blind dictionary attacks toward a
single entry point will call from some savvy implementation advice.
For example, centralized discovery could count failed attempts and
block a user when that number becomes comparable to her password's
entropy.  She won't be able to install new client devices for a while,
but that is much less disruptive than blocking IMAP access.

jm2c

Re: APPSDIR review of draft-ietf-appsawg-media-type-regs-07

Ned Freed — 2012-05-25T01:30:51

dictionary.com defines provisional as:

1. providing  or serving for the time being only; existing only until
   permanently or properly replaced; temporary: a provisional government.

2. accepted or adopted tentatively; conditional; probationary.

Seems to me these definitions both fit the provisional media type registry
quite well, especially the first one.

As for RFC 3864, the provisional registory is pretty clearly intended to be
used not just for entries where the intent is to move them to the permanent
registory eventually, but also for entries that are, well, permanently
provisional, which per the above definition is close to, if not actually, an
oxymoron. Maybe my reading is wrong and such registrations weren't the intent,
but since the registry has been used that way (RFC 6109 is a good example of
this), that seems to be a moot point.

So the terminology misuse seems to be on the part of RFC 3864. Per an earlier
message from Graham Klyne on this general topic, I would suggest that in the
future th

Re: APPSDIR review ofdraft-ietf-appsawg-media-type-regs-07

Mark Nottingham — 2012-05-25T02:43:18

On 25/05/2012, at 11:51 AM, John C Klensin wrote:


Works for me. 

--
Mark Nottingham   http://www.mnot.net/

Re: Looking to begin discussion about email and IPv6

John Levine — 2012-05-25T02:11:16

[ someone noted limited interest in v6 mail ]

I think the main reason is that nobody in North America or Europe sees
any but hypothetical reasons to accept v6 mail any time soon.  I do,
and I can assure you that 100% of the mail I get on v6 could equally
well have been sent on v4.  If it were up to me, I would put all of my
v6 effort into web services, which loses a lot more with NAT or
proxies than mail does.

There's two basic problems with v6 whitelists: making them and using them.

For using them, we have a version of rbldnsd with basic v6 support,
but nobody has any real idea how well it'll work, because we don't
understand very well how DNSxL traffic caches.  If you're a large
provider and can run rbldnsd or the equivalent on the same LAN and
have the sophistication to fetch or manage the DNSxLs it serves,
caching doesn't matter, but for everyone else it does.  The limited
data I have is utterly unclear about practical v4 DNSBL cache
behavior.  At the very low end, it doesn't cache and doesn't matter,

Re: APPSDIR review of draft-ietf-appsawg-media-type-regs-07

John C Klensin — 2012-05-25T01:51:56


--On Friday, May 25, 2012 11:23 +1000 Mark Nottingham
<mnot< at >mnot.net> wrote:


Yes.  The 3864 definition, as I understand it, is closer to
"trial use, incomplete information, might change" while this is,
as Ned points out, is closer to "reserve name during
standardization".  If you think that is excessively confusing,
I'd be open to calling this one something more like "temporarily
reserved" or, to borrow a note from a couple of ISO Maintenance
Agencies "exceptionally reserved", rather than "provisional".
My objection, as Ned suggested, is any hint of "this will be
standardized so start using it based on what you think the
standard will be.    Those who want the standards track
registrations need to accept that they are tied to a consensus
process and that those not only take time but can result in
changes.   Those who need "fast" and/or "open to implementation
even the definitions are woefully incomplete" should use the
vendor or personal trees.

   john

Re: APPSDIR review ofdraft-ietf-appsawg-media-type-regs-07

Mark Nottingham — 2012-05-25T01:23:30



I think the underlying problem is that "provisional" is used in a different sense in RFC3864. I'm not saying it's the *right* sense, but having two different meanings for the same term in somewhat related registries isn't optimal.


--
Mark Nottingham   http://www.mnot.net/

Re: APPSDIR review of draft-ietf-appsawg-media-type-regs-07

Ned Freed — 2012-05-25T01:17:12


The point of the provisional registry is to reserve the name so standards
can be written and trial implementations developed without having to go
through a subsequent name change.

It is *not* there so that random people can look up and start using the type.
Which is very likely to happen if there isn't a clean separation.

If the IESG feels differently, we'll see. But I am absolutely and totally
opposed to these not being separate, and at least one of my coauthors (John)
has indicated that if anything, he's even more opposed to it than I am.

Ned

Re: APPSDIR review ofdraft-ietf-appsawg-media-type-regs-07

Peter Saint-Andre — 2012-05-25T00:23:59

+1

Re: APPSDIR review ofdraft-ietf-appsawg-media-type-regs-07

Mark Nottingham — 2012-05-25T00:08:22

On 25/05/2012, at 3:47 AM, John C Klensin wrote:


For the record, it doesn't work for me. Having a separate list forces people to check two separate lists, causing confusion and reducing the overall value of the registry (we already have a problem with people using Wikipedia instead of IANA).

Regards,

--
Mark Nottingham   http://www.mnot.net/

Re: APPSDIR review of draft-ietf-appsawg-media-type-regs-07

John C Klensin — 2012-05-24T17:47:53


--On Thursday, May 24, 2012 09:49 -0700 Ned Freed
<ned.freed< at >mrochek.com> wrote:

 

FWIW, it works for me.

Also FWIW, IANA used to accept "hidden" or private entries in
some registries.  For them, either only the identifier was
visible to the public or nothing at all was visible but the name
or number would not be available for reuse or use by others.  In
those cases, IANA required documentation supporting the
registration and descriptions of what it was for, but was
willing to keep those confidential (under NDA) for some
negotiated period of time.

As far as I know, that practice ended with the transfer of IANA
responsibility from USC-ISI to ICANN.  Answers to questions in
the first half of the last decade indicated that it was no
longer being done; if that has changed more recently to
reinstate the older practice, I don't believe the community (or
even the IAB) has been told about it and believe that both would
have been.

More important, as Ned points out, this really has nothing to do
with the presen

Re: APPSDIR review of draft-ietf-appsawg-media-type-regs-07

Ned Freed — 2012-05-24T16:49:09

I ask again: How many registration setup specifications have you seen that make
a point of stating that the information they cantain is supposed to be public?
You have yet to provide a single example. And a particularly relevant
counterexample is RFC 3864, which set up the provisional header field registry.
Nowhere did the IANA directions in that document say that the registry needed
to be public, yet it ended up that way. So the default is clearly public and an
explicit statement is required for a registry to be private.

But that said, this nonsense needs to stop, and if changing the wording is the
only way to accomplish that, so be it. How about:

  Standardization processes often take considerable time to complete. In order
  to facilitate prototyping and testing it is often helpful to assign
  identifiers, including but not limited to media types, early in the process.
  This way identifiers used during standards development can remain unchanged
  once the process is complete and implementations and do

Re: Aggregated service discovery

Peter Saint-Andre — 2012-05-24T16:23:48

Yes, we've had service discovery methods in XMPP for over ten years (in
fact the following spec superseded an older method in use since 1999):

http://xmpp.org/extensions/xep-0030.html

Because XMPP native includes presence "push", we also have a dynamic
profile of service discovery for real-time capability changes:

http://xmpp.org/extensions/xep-0115.html

Peter

Re: Aggregated service discovery

Paul E. Jones — 2012-05-24T16:19:10

Cyrus,

I apologize for not replying sooner.

I do believe WebFinger could be used to locate these services.  I wasn't
aware of RFC 6186 (and rushed right out to add it to my domain), but
WebFinger could be used to provide an even better level of granularity.  It
exists now, so I'm not sure if one would want to migrate to WebFinger, but
if it did I can imagine something like this:

GET /.well-known/host-meta?resource=mailto:paulej< at >packetizer.com

Returning...

{
  "subject" : "mailto:paulej< at >packetizer.com",
  "links" :
  [
    {
      "rel" : "config-email",
      "href" : "http://www.packetizer.com.com/config/email/?user=paulej"
    }
  ]
}

The above document would include a link relation that refers to mail server
configuration.  Querying the /config/email/ URI might return a JSON document
like this:


  {
    "imaps" : "cluster23.imap.packetizer.com",
    "smtp-submission" : "smtp.packetizer.com"
  }

(Note: this is a trivial example, whereas we'd probably need to indicate use
of SSL, TLS, login requirem

Re: The acct: scheme question

Paul E. Jones — 2012-05-24T15:15:05

John,

It seems that most people largely agree with the procedures we've defined
now; I've seen no other proposed changes (noting -05 contained only a very
few).  It also seems that most people see the utility for "acct", even
though other URIs might be used for some use cases (e.g., mail client
configuration or XMPP client configuration).

The only remaining concern I see is with approval of "acct" and delays that
might happen.  I think that if properly positioned for what "acct" is, it
would be opposed.  If there was opposition, though, we could always split
the draft into two pieces in order to get the draft moved to RFC status.  Of
course, I'd prefer to keep all of the text together, but I would prefer to
not hold up progress on OpenID Connect.

Paul

Re: Aggregated service discovery

Michiel de Jong — 2012-05-24T14:30:03

i find this a super interesting question. i have been thinking about
this as well, and i think we don't have a good solution for this right
now, so it would be cool to change that. aspects i see:

1: Existence - listing which services even exist
2: Version - which version of the spec the instance claims to be compliant with
3: End-points - this is service-specific
4: Options - which types of encryption, signature, encodings, etc. are supported

i think these 4 types of discoverable information make sense for most
services. And i think if we combine webfinger/swd with json-home, then
we probably have enough expressive power to announce these 4 types of
information in a sensible way.

but the main objection people would have to doing this is i think
privacy/security. you don't want to announce the exact details of all
your services publically, because:
1) it makes it easier for an attacker to know where to attack your systems
2) it may reveal non-public information about your users unnecessarily.

Given that

Re: The acct: scheme question

John Bradley — 2012-05-24T14:27:21

The question comes down to the same one that has been discussed in the past.

What to use as a abstract identifier for a user.

I am sympathetic to the use of acct:

However I have not been convinced that it belongs in WF directly.

Until acct: is an approved URI I am not keen to have openID Connect take a normative reference to it.

If the WG and the chairs decide to do it as one spec,  that will likely impact our decision to reference WF for discovery.

That is just a personal opinion and the Connect WG will need to take the decision.

John B.


On 2012-05-24, at 10:03 AM, Paul E. Jones wrote:

Re: The acct: scheme question

Melvin Carvalho — 2012-05-24T14:18:33


Let me make an analogy with a relational database:

Consider you had a database table of information about a user.  One field
in the table is a (unique) email address and you wish to get the whole row,
which may contain things like blog and name, but could be any number of
fields.

The acct: protocol says the folloiwng:  'we should look up the table record
by the primary key, which is not the email address'.  Since we dont know
what the primary key is, let's give it a name : 'acct:user< at >host'.  Then we
can look things up.

There's a few challenges with this:

- it assumes lookup by "foreign" key (email) is problematic, which it need
not be

- if there is an existing primary key the acct: scheme may not be needed or
wanted

- it transitions the social web to a world where users will necessarily
have a keyring of multiple identifiers to carry out a cross platform lookup
(for example facebook already use http uris in their graph) making
implementations more complex

- developers and implementors may get confus