Lisa's Apps Area Activity Report for Oct 2009

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

RE: host-meta: template syntax hassles

This subject was discussed at length this week at IIW. The strong consensus was that since the currently
proposed template vocabulary isn't expressive enough, it should be made even less expressive (only
define 'uri') and not more expressive (see one proposal below). The main argument were:

- A future (richer) template syntax will address empty variables and the proper assembling of URI
components together. When it becomes available, host-meta could be updated to define the full set of
variables to support such common transformations.

- Any vocabulary breaking the context URI into parts will need a complimentary method for applying links to
resource subsets (at least based on the URI scheme). For example, it is not likely that a single template
(using variables other than 'uri') will be able to properly address both 'http' and 'xmpp' URI transformation.

The second point is the most important in my view since it requires extending the proposed document format
to directly support describing subsets of resources. I am more inclined to reduce the vocabulary to a
single 'uri' variable than extend both the vocabulary and schema to support richer scheme or pattern
specific transformation.

Since host-meta allows protocols to define their own 'rel'-specific template syntax and vocabulary,
individual protocols with such needs will still be able to make use of the framework. In addition, servers
can always use a simple redirection script to redirect a client to a more complex location than provided by
a single 'uri' variable.

Comments?

EHL


> -----Original Message-----
> From: apps-discuss-bounces <at> ietf.org [mailto:apps-discuss-
> bounces <at> ietf.org] On Behalf Of Manger, James H
> Sent: Tuesday, October 27, 2009 3:52 PM
> To: apps-discuss <at> ietf.org
> Subject: RE: host-meta: template syntax hassles
> 
> One solution (for simple, but correct, URI templates for common
> situations in host-meta) is to define more variables.
> 
> For instance, in addition to 'scheme', 'authority', 'path', 'query'...
> offer the following variables:
>
> 'toDir' — the URI up to, but excluding, the last '/' in the path
> 'afterDir' — the URI from the last segment of the path to the end, excluding the fragment
> 'toExt' — the URI up to, but excluding, the last '.' in the last segment of the path (or to the end of the path
if there is no such dot)
> 'toPath' — the URI up to the end of the path
> 'afterPath' — the URI from after the path to the end, excluding the fragment
> 'toQueryPlus' — the URI excluding any fragment, followed by '&' if there is a query string or '?'
otherwise (ie ready for a new query parameter to be appended)
> 'beforeHost' — the URI up to, but excluding, the host
> 'fromHost' — the URI from the host to the end, excluding the fragment
> 
> Template examples:
> {+toExt}.xrd{+afterPath} — replace, say, .html extension with .xrd to get metadata
> {+toQueryPlus}_=meta — add a query parameter named “_” with a value “meta” to get metadata
> {+toDir}/.meta/{+afterDir} — metadata is in a special .meta/ subdirectory of each directory
> {+toPath};meta{+afterPath} — append “;meta” to the path to get the metadata
> {+beforeHost}meta.{+fromHost} —metadata is hosted on a sub-domain
> 
> The to/after (and before/from) pairs basically offer easy access to
> different points in the URI to insert a new element. I think these
> examples are fairly simple ways to implement common URI manipulations
> safely.
> 
> James Manger
> James.H.Manger <at> team.telstra.com
> Identity and security team — Chief Technology Office — Telstra

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

Re: Last Call: draft-nottingham-site-meta (Defining Well-Known URIs) to Proposed Standard

Eran Hammer-Lahav wrote on 10/13/2009 6:53 PM: 
> I think it would be premature to define this before we have a few
> items in the registry and see how it is used.

FWIW, I brought up /.well-known/ for Mozilla's 'autoconfig' feature that is currently being developed:

	http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/18be26ee250a53b5

If they decide to implement /.well-known/, that's one way in which it'll be used.

- Bil

Updated Apps Area agenda for tomorrow

Here is the current list of topics I have so far:

1) Dan Wing: short announcement of GROBJ BOF (10 mins)
2) Dan Wing <dwing <at> cisco.com>: Building IPv6 Applications which Access 
IPv4 Servers (draft-wing-v6ops-v6app-v4server-01.txt) - 15 mins
3) Peter Saint-Andre <stpeter <at> stpeter.im>: Apps Review Team - 5 mins
4) Peter Saint-Andre <stpeter <at> stpeter.im>: TLS server identity checks in 
application protocols (draft-saintandre-tls-server-id-check) - 20 mins 
[with discussions]
5) Magnus Westerlund <magnus.westerlund <at> ericsson.com>: IANA ports and 
service names registry - 20 mins [with discussions]
6) John C Klensin <john-ietf <at> jck.com>: FTP commands and extensions 
registry - 15 mins
7) Spencer Dawkins <spencer <at> wonderhamster.org>: 
Subscription/Notification for Lightweight Directory Access Protocol 
(LDAP) (draft-dawkins-ldapext-subnot-01.txt) - 20 mins

45 mins for the remaining of the session:
8) Short presentations about other Apps BOFs
9) Open mic

quick update on calsify

Lisa, Alexey, all,

Since I won't be in Hiroshima, I thought I would give you and this group
a brief update on where things are with Calsify.  Although it has taken
us a bit longer than anticipated, we have gotten an update to RFC 2445
out the door.  That is RFC-5545.  We now anticipate smooth sailing for
draft-ietf-calsify-2446bis, which Cyrus has completed.  Next up is
draft-ietf-calsify-rfc2447bis, which is just about ready for WGLC.  What
is holding it up right now is me, as I want to check all of the
examples, and provide some additional Security Considerations text.  In
the meantime, I ask that people take a good look at the document and
provide the author or the Calsify working group comments.

After this document is published, the chair (I) will engage in a
discussion first with the ADs and then with the broader community over
what if anything should happen next in Calsify.

Thanks to the authors, Bernard, Cyrus, and Alexey, for their work, and
for the chairs' and community's patience in getting these updates done.

Eliot

quick update on metalink

Lisa, Alexey, and everyone else,

None of the metalink authors will be in Hiroshima (although some of us
are trying to make Anaheim in March).

We think draft-bryan-metalink is ready for last call. We have another
revision waiting to submit that incorporates suggestions from Mark
Baker via apps-review & PSA. Currently, 4 apps support this with more
on the way.

draft-bryan-metalinkhttp is a work in progress, specification wise,
but functionality wise appears relatively stable. Most reception has
been positive, at least of the ideas inside. We have a revision with
Micah Cowan's (wget) suggestions waiting to submit.
This draft is complementary to metalink (XML), not seen as competition
or replacement, and can be used in less situations. Only 2 apps
support it and we have lots of testing ahead of us.

draft-bryan-http-digest-algorithm-values-update, "Additional Hash
Algorithms for HTTP Instance Digests" is the update to the Instance
Digests registry. This draft is rather short and simple. I think it is
basically done, but welcome all comments of course.
--

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

service names - one registry vs. two registries

Hi,

as just briefly discussed in the APP area meeting after Joe's  
presentation, we need to come to some community consensus on what to  
do with service name registrations.

draft-ietf-tsvwg-iana-ports has been written with the intent to unify  
the three(*) current places where service names can be registered,  
making the ports and service names registry the one-stop shop for  
ports and service names. All service names (~10K?) registered in one  
of the current three places would be grandfathered in.

draft-gudmundsson-dns-srv-iana-registry advocates a creating new  
standalone registry for service names that are to be used with DNS SRV  
RRs (exclusively, in my reading) and seed it with only those 40  
service names that are specifically called out in published RFCs.  
There is no discussion on how the new registry relates to the three(*)  
existing places where service names have currently been registered.

(Disclaimer: I'm an author of draft-ietf-tsvwg-iana-ports, so you  
should read the two documents to form your own opinion on the  
different proposals.)

So far, the discussion has mostly seen arguments from the proponents  
of both approaches. It would be useful to hear from the broader  
community on which general approach is preferable.

Lars

(*)
http://www.iana.org/assignments/port-numbers
http://www.iana.org/assignments/service-names
http://www.dns-sd.org/ServiceTypes.html

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

RE: host-meta: template syntax hassles

> the currently proposed template vocabulary..
> should be made even less expressive (only define 'uri')

I (somewhat reluctantly) agree, as long as the '+' operator (don't %-escape reserved chars) is removed as well.

A decent aim is to support just the simplest case now (eg
<URITemplate>http://example.com/meta?u={uri}</URITemplate>), and try to be compatible with a
future fully-developed URI template spec. The behaviour with unrecognised variables, and unexpected
syntax is more important than the list of variables defined.

The '+' operator should NOT be defined in hostmeta (if the only variable is 'uri'). It is not necessary for
the simplest case. I don't think it can be used safely with the 'uri' variable. A template like "{+uri};by"
almost looks sensible, but it isn't. The ";by" suffix may be appended to the path (if there are no query
params), to the last query parameter value, to the top-level domain (if the path is empty) etc.

hostmeta-02 says to ignore <Link>s containing templates with unrecognised variables, eg {blurg}. A
future template spec is more likely to say to substitute an empty string "" in this situation.
Ignoring <Link>s with unrecognised variables is ok in host-meta, though just giving them a lower priority
than <Link>s with known variables may be better (substituting an empty string for the unrecognised
variables). Priorities add a bit more complexity, and you can have any number of <Link>s with a given
relation in host-meta, so I ignoring the whole <Link> is ok.

hostmeta-02 says to ignore <Link>s containing templates with an unexpected syntax (ie containing chars
not allowed in a variable name, eg {/blurg}). I agree with this (it is unclear what a future template spec
will say in this case). Since I think the '+' operator does not need to be defined at this point, any link with
{+uri} would also be ignored.

James Manger

Re: service names - one registry vs. two registries

On Sun, Nov 8, 2009 at 6:21 PM, Lars Eggert <lars.eggert <at> nokia.com> wrote:
> Hi,
>
> as just briefly discussed in the APP area meeting after Joe's presentation,
> we need to come to some community consensus on what to do with service name
> registrations.
>
> draft-ietf-tsvwg-iana-ports has been written with the intent to unify the
> three(*) current places where service names can be registered, making the
> ports and service names registry the one-stop shop for ports and service
> names. All service names (~10K?) registered in one of the current three
> places would be grandfathered in.
>
> draft-gudmundsson-dns-srv-iana-registry advocates a creating new standalone
> registry for service names that are to be used with DNS SRV RRs
> (exclusively, in my reading) and seed it with only those 40 service names
> that are specifically called out in published RFCs. There is no discussion
> on how the new registry relates to the three(*) existing places where
> service names have currently been registered.
>

Well, it certainly seems valuable to me to distinguish between the
cases where you can expect to use SRV and those you cannot (the same
for NAPTR or UNAPTR or DDDS).  Whether you distinguish that by a field
in a single registry or by having multiple registries which don't have
overlapped names kind of doesn't make that big a difference to my way
of thinking.

regards,

Ted

Re: service names - one registry vs. two registries

my 2 cents:
- roughly, it does not matter.
- I have a slight bias towards one single registry so that all 
assignments related to "transport services" are in one place. simpler 
for implementors, for protocol designers, etc... so voting for one 
registry for easier to find info.

Marc.

Lars Eggert a écrit :
> Hi,
> 
> as just briefly discussed in the APP area meeting after Joe's 
> presentation, we need to come to some community consensus on what to do 
> with service name registrations.
> 
> draft-ietf-tsvwg-iana-ports has been written with the intent to unify 
> the three(*) current places where service names can be registered, 
> making the ports and service names registry the one-stop shop for ports 
> and service names. All service names (~10K?) registered in one of the 
> current three places would be grandfathered in.
> 
> draft-gudmundsson-dns-srv-iana-registry advocates a creating new 
> standalone registry for service names that are to be used with DNS SRV 
> RRs (exclusively, in my reading) and seed it with only those 40 service 
> names that are specifically called out in published RFCs. There is no 
> discussion on how the new registry relates to the three(*) existing 
> places where service names have currently been registered.
> 
> (Disclaimer: I'm an author of draft-ietf-tsvwg-iana-ports, so you should 
> read the two documents to form your own opinion on the different 
> proposals.)
> 
> So far, the discussion has mostly seen arguments from the proponents of 
> both approaches. It would be useful to hear from the broader community 
> on which general approach is preferable.
> 
> Lars
> 
> (*)
> http://www.iana.org/assignments/port-numbers
> http://www.iana.org/assignments/service-names
> http://www.dns-sd.org/ServiceTypes.html
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Apps-Discuss mailing list
> Apps-Discuss <at> ietf.org
> https://www.ietf.org/mailman/listinfo/apps-discuss