Fwd: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT)

[Melvin Carvalho]

FYI: the "DISCUSS" status is a blocking state

---------- Forwarded message ----------
From: Pete Resnick <pres...@qti.qualcomm.com>
Date: 10 April 2013 17:13
Subject: [webfinger] Pete Resnick's Discuss on draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT)
To: The IESG <ie...@ietf.org>
Cc: webf...@ietf.org, appsawg...@tools.ietf.org, draft-ietf-app...@tools.ietf.org


Pete Resnick has entered the following ballot position for
draft-ietf-appsawg-webfinger-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.




----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[All: As I noted earlier to the Webfinger mailing list, I have Cc'ed this
to the Webfinger list along with the document authors, the document
shepherd, and the rest of the IESG.

Also note that I intend to DISCUSS this until Thursday. If I get no
further support from the IESG and/or the WG that this is a serious and
showstopper problem, I will simply ABSTAIN on both this and on the
-acct-uri document (on which I also currently have an open DISCUSS
position). But it looks like Richard and I are in some agreement on
this.]

There appears to be a big giant semantic gap for the client side of this
protocol. I can find nothing in the document that indicates to the client
how it shall determine what sort of URI to use is the resource part of
the query or what the semantics of any given URI are supposed to be. I
suspect that the semantics are so underspecified that there could not
possibly be interoperable implementations without lots of out-of-band
information.

The first example provides a mapping from an email address (or perhaps a
mailto URI; that's not clear) to an acct URI, but neither the example nor
anything in the rest of the document gives any clue why you would choose
to query an "acct" URI based on the contents of an email message. I think
the assumption is that if there is an email address, there must be some
sort of "account" associated with it, and therefore querying the host on
the RHS of the "@" for that account will get some interesting
information. But I don't see any reason to choose an "acct" scheme over
"mailto" or "smtp" or "email" or "foobar"; as far as I can tell, the
choice is semantics-free.

Reading the above alongside 3.3 makes me all the more suspicious: In 3.3
(also mentioned in 4.5), a "mailto" URI gets you configuration
information for all email configuration parameters. Does an "acct" URI
get you configuration information for email *and* xmpp *and* sip *and*
calendaring *and* all other configuration information (since you are no
longer asking for a particular protocol, but rather the general account
information), or do you only get "information" about the person and not
their account? (I might also insert privacy and security worries here,
but see Stephen's DISCUSS regarding that.) How can the client know what
sort of information it can ask for and how to get it? And for that
matter, how does the server tell what information to pass back? You'd
think there would be a hint about this in 4.3, but "rel" only seems to
provide for the client to request those things that the client already
knows about it. In particular, there appears to be no way to say, "Give
me user provided information, but not config information" or "Give me
config information, but not blog entries".

I find the semantics for "device" in 3.4 all-the-more mysterious. As far
as I can tell, this URI scheme simply means, "Give me all of the
information for the entire host."

Again, the semantics of all of these interactions seem so underspecified
that I don't understand how interoperation is supposed to happen.

This also leaves me with the question about why the resource query part
is a URI at all. It seems to me that the resource you are asking about is
not a URI (or URN) at all; it's simply an identifier for an entity that
the particular host knows about. Given that, why not pass a simple
identifier? (See http://datatracker.ietf.org/doc/draft-ietf-radext-nai/
for example.) If the scheme is not providing any particular semantics
about the response, I see no reason to provide the scheme. If more
semantics (beyond rel) are needed, another parameter indicating the type
of identifier being used seems much more appropriate than using a URI
scheme.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Stephen's concerns re: privacy.


_______________________________________________
webfinger mailing list
webf...@ietf.org
https://www.ietf.org/mailman/listinfo/webfinger

[Michiel B. de Jong]

On 2013-04-11 11:21, Melvin Carvalho wrote:
> FYI: the "DISCUSS" status is a blocking state
>
> ---------- Forwarded message ----------
> From: PETE RESNICK <pres...@qti.qualcomm.com [1]>
> Date: 10 April 2013 17:13
> Subject: [webfinger] Pete Resnicks Discuss on
> draft-ietf-appsawg-webfinger-12: (with DISCUSS and COMMENT)

> To: The IESG <ie...@ietf.org [2]>
> Cc: webf...@ietf.org [3], appsawg...@tools.ietf.org [4],
> draft-ietf-app...@tools.ietf.org [5]
> [...]

thanks for the forward!

for https://github.com/remotestorage/spec we'll just use whatever is
the latest webfinger draft at the moment we tag each version. if the
IETF process blocks, then that just means we will use whatever was the
last version before the block occurred. :)


Cheers,
Michiel