gmane.ietf.apps-discuss

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 *yet* exist, it also deviates
from host-meta, so that doesn't change
- it could lead to rejection-domino, should acct: get rejected
- it involves dropping bare user addresses, and Blaine already said
he's "completely and utterly" opposed to that.

I'm in favour of option 1, and from what i read, some more people are.
Some other people have stated they are simply not interested in making
the scheme-less case work, which is fair enough. I don't think anybody
is in favour of suspending production use until we get an answer about
the proposed URI scheme, although I might be wrong. There are probably
some other positions which i'm underrepresenting here, sorry if that's
the case.

But when phrased this way, is anybody in favour of option 2?

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 these not-really-provisional provisional registries be called
"informational" registries instead, since that term seems to fit their purpose
far better than the term "provisional" does.

Of course it is too late to change either RFC 3864 (or RFC 4395, which is very
similar), but redefining the word "provisional" is also a bit beyond our
purview. So we really have no choice but to live with the discrepancy.

Getting back to the provisional media types registry, if we really wanted an
alternative "pro tem" is also a good fit, but  changing the terminology to what
pretty much has to be a synonym for provisional doesn't really solve the
problem.

Ned

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,
for some kinds of woodpeckering it does cache which does help, in
between, who knows.

For making them, the problem is how you come up with a registration
system that is simple enough that unsophisticated MTA operators can
use it, but hostile enough that bots can't script it, not unlike the
problem of webmail signups.  If we could figure that out, we could at
least try some experiments.

Regards,
John Levine, johnl< at >iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

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 present document -- there are all sorts of obvious
things it could say that it doesn't.  Statements like
"registration data are public except maybe in very unusual cases
that the registry-creating spec must explicitly enable and this
media type registry specification doesn't do that" and "the IANA
doesn't get to decide on the validity of an IESG determination
of consensus for for a IETF-based standards track registration"
are certainly on that list of obvious things that shouldn't need
debate or writing down, but so is "no registrations will be
updated on the 29th of February in odd-numbered years".

While the material has been restructured and reorganized several
times to meet changing needs, there are many basic principles
that are unchanged since the registration provisions of RFC
1590.  Might it be reasonable to suggest that, if no real and
substantive problems have turned up in those basic principles in
the last 18 years, an "ain't broke, doesn't need fixing"
guideline might apply?

   john

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 documentation do not
  have to be updated.

  Accordingly, a provisional registration process is provided to support early
  assignment of media type names in the standards tree. A provisional
  registration MAY be submitted to IANA for standards tree types. The only
  required fields in such registrations are the media type name and contact
  information (including the standards body name).

  Upon receipt of a provisional registration, IANA will check the name and
  contact information, then publish the registration in a separate publicly
  visible provisional registration list.

  Provisional registrations MAY be updated or abandoned at any time. When this
  happens the media type is no longer registered in any sense; it can
  subsequently be registered just like any other unassigned media type name.

This intentionally leaves open whether or not any indication of abandoned
registrations should be visible. That can and should be IANA's call.

Does this work for you?

Ned

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 requirements, etc.)

It would accomplish something similar to SRV records, but provide a finer
level of granularity to allow domain owners to assign users to different
machines and specific configurations.

Paul

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 the user story Andrew describes (and i think this is the
correct thing to be looking at), starts out with a domain identifier,
a user identifier within that domain, and some authentication
token(s). If we have a trusted client then we can already use those
tokens during the discovery. In other cases we would have to use maybe
OAuth or similar to get derived tokens for doing the actual discovery.
If we do that, then we need to announce that that is the case. In the
case where you use resource owner password credentials, then i can see
how you could discover everything you want in 1 round trip. if you use
derived credentials (e.g. implicit grant), then i think 3 round-trips
are unavoidable: one to discover the discovery and OAuth end-points,
one to obtain the derived token, and one to do the actual lookup with
it.

My 2ct,
Michiel

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 confused of when to use mailt: acct:
or just user< at >host

- it's going to take many years (both time and work) for this to become
anywhere near as mainstream as http: or mailto:

If the payoff is considered worth the effort, then I think that's probably
fine.  Personally I think acct: should have it's own document.  Perhaps if
it's ultra simple (under 1 page as it is now) it can get approved very
quickly.


_______________________________________________
apps-discuss mailing list
apps-discuss< at >ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss

Re: Aggregated service discovery

Michiel de Jong — 2012-05-24T14:11:04

sure, so for xmpp service it makes sense to use the existing xmpp
disco, which is non-http. but the question is whether it makes sense
to have a way to /list/ services, rather than relying on the app to
know what to ask for.

if you're going to provide a list, then that has to be on 1 specific
platform. http seems a good choice for that.

it's a choice between server-side aggregation or client-side
aggregation of this list.