gmane.ietf.apps-discuss

Re: Aggregated service discovery

Michiel de Jong — 2012-05-23T10:33:34

IMO, webfinger/swd is the way to go. they are currently being merged
into one. All discovery paths should use webfinger/swd as the first
step, and then do other stuff (including requiring credentials) in
documents linked from there. There are cases where a service is
specific to a domain, but not to a user, but I think they should still
also be announced from the same first starting point (which is
/.well-known/host-meta).

how to deal with private information (meant only for the user
themselves), is not very well documented. the webfinger/swd spec
basically leaves it out of scope. Basically what you would do IMO is,
for a user "<user>< at ><host>", announce a first starting point at
https://<host>/.well-known/host-meta, and then use "follow your nose"
to discover everything else. That includes discovering the home-pages
of any domain-specific APIs, as well as caldav, BrowserID, OpenID,
ActivityStreams, foaf, PoCo, remoteStorage, email addresses, avatars,
and everything else. The first starting point should be av

Re: The acct: scheme question

Martin J. Dürst — 2012-05-23T06:42:49

I have explained earlier that this is not an option. $username is not 
the user *about* which you want information, but the user who *accesses* 
the server.

To give a specific example, if you use an URI such as:

http://john_bradley< at >www.ietf.org/

then e.g. on Firefox, I get the following message:
    You are about to log in to the site "www.ietf.org" with the username
    "john_bradley", but the website does not require authentication.
    This may be an attempt to trick you.

Under the hood, "john_bradley" is being sent in the relevant http header(s).

Regards,   Martin.

 er it should be split from the original WF doc or not.

Re: Aggregated service discovery

Mark Nottingham — 2012-05-23T06:29:24

If they're HTTP - <https://datatracker.ietf.org/doc/draft-nottingham-json-home/>

Not yet convinced that well-known is needed for this yet; it's effectively substituting a hostname for a full URL.

Cheers,


On 23/05/2012, at 1:00 AM, Cyrus Daboo wrote:


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

Re: The acct: scheme question

William Mills — 2012-05-23T03:25:19

Better to go with no scheme than use http.




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

I-D Action:draft-ietf-appsawg-media-type-suffix-regs-01.txt

2012-05-23T02:13:03

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Applications Area Working Group Working Group of the IETF.

Title           : Additional Media Type Structured Syntax Suffixes
Author(s)       : Tony Hansen
Filename        : draft-ietf-appsawg-media-type-suffix-regs-01.txt
Pages           : 9
Date            : 2012-05-22

   A content media type name sometimes includes partitioned meta-
   information distinguish by a Structured Syntax, to permit noting an
   attribute of the media as a suffix to the name.  This document
   defines several Structured Syntax Suffixes for use with media type
   registrations.  In particular, it defines and registers the "+json",
   "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" Structured Syntax
   Suffixes, and updates the "+xml" Message Type Structured Syntax
   Suffix registration.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-suffix-regs-01.txt

Re: The acct: scheme question

Ted Hardie — 2012-05-23T00:40:48

Actually, a URN namespace will not work here, because the domain name
system does not meet the requirements of a persistence required for a
URN.  This is explained in RFC 3405, but a quick excerpt of the larger
text is:

   For the purposes of URNs, a "namespace" is a collection of uniquely-
   assigned identifiers.  That is, the identifiers are not ever assigned
   to more than 1 resource, nor are they ever re-assigned to a different
   resource.

Since domain names can change hands (for example, when the
organization previously running that domain is purchased), there is no
inherent guarantee that username< at >domainname.example is permanent.


regards,

Ted Hardie

Re: The acct: scheme question

John Bradley — 2012-05-23T00:39:47

URN don't have authority portions, so may not be a good fit.

The authority segment is necessary to bootstrap the resolution process.

How about we do the core spec with http://$username< at >$domain

If we are not intending to have a special protocol handler then http: should work just fine.

The link relationship doesn't need to be a custom scheme.

Whatever Connect references  is going to be around for a long time,  later could be awkward.

John B.

On 2012-05-22, at 7:58 PM, William Mills wrote:


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

Re: The acct: scheme question

William Mills — 2012-05-22T23:58:52

How about we go with the current draft, and if we hit a significant headwind, we break it out and deal with it separately.

If we hit a headwind we couldgo with a few more characters and use urn:acct:$username< at >$domain. Probably easier to register with IANA a new URN namespace and we're done.


-bill





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

APPS area review of: draft-ietf-abfab-gss-eap-06

William Mills — 2012-05-22T23:31:08



Major:

Section 5.8: still lists "Open issue: handling of lifetime parameters."

Minor:

Section 3.4: "RFC editor, remove the remainder of this subjection prior to publication.", do you mean "subsection" here? 


Section 5:  The format of "length" should be more clearly defined her.  A more detailed definition appears to live as the last three sentences in 5.6.3, which seems odd.


Nits:

Section 5.5.1 & 5.5.2: Is the phrase "It is always critical." something with specific meaning?  Otherwise simply stating that these tokens are REQUIRED, is probably sufficient.

Section 6: 3rd paragraph, "procedur" needs an "e" on the end.


Section 7.1:  "[this spec" wants a closing square bracket.

Section 7.3:  The choice of registered values seems odd;  non-sequential, and slightly inconsistent (request vs. response not in consistent numerical order).  Doesn't matter since it's constants._______________________________________________
apps-discuss mailing list
apps-discuss< at >ietf.org
https://www.ietf.org/mailman

Re: The acct: scheme question

Bob Wyman — 2012-05-22T23:29:59

I would very much prefer that we do NOT create a new WG but rather proceed
with acct: as part of WebFinger.

WebFinger is designed to work with any URI -- but it needs acct: since what
acct: does is not currently done by any other URI scheme.

bob wyman

On Tue, May 22, 2012 at 6:22 PM, Gonzalo Salgueiro <gsalguei< at >cisco.com>wrote:

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

Re: The acct: scheme question

Gonzalo Salgueiro — 2012-05-22T22:22:58

On May 22, 2012, at 3:23 PM, Barry Leiba wrote:


After having just completed the long drawn out process of authoring a controversial charter that was agreeable to all and finally forming a WG, I would really prefer if we can avoid all that overhead and delay.  We all share the common goal of a robust discovery protocol delivered as expeditiously as possible. I feel we have come a long way given that both camps (SWD and WF) have made concessions and came to an agreeable initial state for a WG draft, along with the maturity of the WF draft and the amount of review and scrutiny it has received from this group I think this is possible if we all remain open-minded and willing to work together.  As far as the acct: URI, I get the sense that most folks don't mind the URI scheme itself. It seems that that the real point of contention is whether 
 it should be split from the original WF doc or not.  

IMO a strong case can be made for the acct: URI scheme being part of the core WF spec considering the existence of

Re: AppsDir review of draft-polk-ipr-disclosure

Adrian Farrel — 2012-05-22T20:48:05

Since Pete is the religious fanatic about BCP classification, I will leave him to answer for draft-farrrrrrrrrrrrrrresnickel (Murray, I think you left out two letter r's).

IMHO this is not trying to direct process, just state what tools are already available, so I am happier with Info.

A

Re: The acct: scheme question

John Bradley — 2012-05-22T20:44:56

The current WF draft is dependent on acct: 

It uses acct in link relations and it normalizes relative URI like jbradley< at >foo.com to acct:jbradley< at >foo.com.

I have been through this before with trying to register xri: with almost the same semantics,  for retrieving XRD about a subject.  I thought it would not be a problem.  That was until the W3C TAG intervened, and effectively blocked the OASIS spec.

You are probably right that there is not issue.  However I prefer to manage the risk by separating them.

John B.


On 2012-05-22, at 4:38 PM, Peter Saint-Andre wrote:

Re: The acct: scheme question

Peter Saint-Andre — 2012-05-22T20:38:06

It does.


It's not.


I'm not sure about that.

Peter

Re: The acct: scheme question

John Bradley — 2012-05-22T20:35:17

While minimizing work is valuable.  Minimizing risk is also.

WF should work with any URI.

It should not be dependant on acct:

acct: will undergo more scrutiny than WF to get approved as a scheme.

John B.


On 2012-05-22, at 3:54 PM, Peter Saint-Andre wrote:

Re: The acct: scheme question

Gonzalo Salgueiro — 2012-05-22T20:20:18

++

My sentiments exactly.

Cheers,

Gonzalo

On May 22, 2012, at 3:22 PM, William Mills wrote:

APPSDIR review of draft-ietf-ledbat-congestion-09

Vijay K. Gurbani — 2012-05-22T20:24:57

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-ledbat-congestion-09
Title: Low Extra Delay Background Transport (LEDBAT)
Reviewer: Vijay K. Gurbani
Review Date: May-22-2012
IETF Last Call Date: Unknown
IESG Telechat Date: May-24-2012

Summary: This draft is ready for publication as an Experimental Standard
but it has some minor issues (detailed below) that should be addressed.

Major issues: 0
Minor issues: 3
Major issues: 2

Minor:

- S3.3: You probably need an accessor to get the timestamp; i.e.:
   OLD:
      remote_timestamp = data_packet.timestamp
   NEW:
      remote_timestamp = data_packet.timestamp()

- S3.3: The text says that the receiver ".

Re: The acct: scheme question

Peter Saint-Andre — 2012-05-22T19:54:52

Probably, yes. Minimizing the work is valuable.

/psa

Re: AppsDir review ofdraft-farrresnickel-ipr-sanctions

Barry Leiba — 2012-05-22T19:32:34

I'm pretty sure this one should NOT be a BCP.  Remember that it
doesn't change ANY procedure or process.  It just points out
alternatives that are already available.

Barry

AppsDir review of draft-farrresnickel-ipr-sanctions

Murray S. Kucherawy — 2012-05-22T19:29:07

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see  http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate<http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate>).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document: draft-farresnickel-ipr-sanctions
Title: Sanctions Available for Application to Violators of IETF IPR Policy
Reviewer: Murray S. Kucherawy
Review Date: May 22, 2012
IETF Last Call Date: ends June 4, 2012
IESG Telechat Date: not scheduled

Summary: This document is ready for publication as an Informational document, modulo my two issues for discussion below.

Major Issues:

1. Should this not be a BCP?  The polk draft describes ways to encourage compliance, while this one talks about penalties for non-compliance.  That seems too severe for Info

Re: The acct: scheme question

Barry Leiba — 2012-05-22T19:23:27

My sense is that given the discussion so far, we can do this without a
BoF.  And I'm starting to be more and more convinced that we need to
take this out of AppsAWG and give it its own working group (though I'm
not certain of that yet, and I haven't talked with Pete about it).

That still means we need a draft charter, probably at least a couple
of weeks for discussion and bashing of it, then at least three or four
weeks for the IESG to process it.  Let's say 6 to 8 weeks, if it goes
efficiently and smoothly.  Add time for glitches if they happen.

If the document can be done in less than, say, 12 to 15 weeks, and if
can get adequate attention, then we should finish it here.  But the
discussion needs to converge.  If it needs more focused attention in
order to converge, then that's a reason to pull it off into a WG of
its own.

Barry