Subject: [Uri-review] IETF ECRIT Working Group: LoST URI Scheme --- Review Needed

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 01 Feb 2007 11:11:31 -0500

Hi all

in the IETF ECRIT working group we have done work on a protocol called 
LoST. The description can be found in:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-03.txt

In Section 4 we define the LoST URI scheme.
The IANA considerations can be found in Section 16.5.

We would like to solicit feedback since we are getting close to finish 
the document.

Ciao
Hannes & Marc

_______________________________________________
Uri-review mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/uri-review

---

From: "Mark Baker" <[email-masked]>
Date: Thu, 1 Feb 2007 15:29:40 -0500

I think section 4 should be expanded to follow the guidelines in RFC
4395 (BCP 115); there's a lot of missing information that we need to
properly review it.

Also, as a comment on the protocol, I find it unfortunate that LoST is
using HTTP as a transport protocol when it appears, after a cursory
read through the draft, that HTTP could be used perfectly well as an
application protocol.  If it were, the implications to the URI scheme
would be different of course; you probably wouldn't need a new one,
AFAICT.

If you are going to continue to use HTTP for transport, I think you
should defend that choice with reference to RFC 3205 (BCP 56).

Mark.

-- 
Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
Coactus; Web-inspired integration strategies  http://www.coactus.com

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 01 Feb 2007 15:58:30 -0500

Hi Mark,

> 4395 (BCP 115); there's a lot of missing information that we need to

Thanks for pointing to it.

Ted is co-authoring RFC 4395. That's good for us.

> should defend that choice with reference to RFC 3205 (BCP 56).
I wonder what other protocol we should have used.

We discussed the usage of UDP but the XML stuff gets too large leading 
to fragmentation = Not Good (tm).
We also discussed SOAP; that does not make things better either.

LoST provides the ability to define new bindings but we thought that 
HTTP would be a pretty good compromise.

Ciao
Hannes

---

From: Ted Hardie <[email-masked]>
Date: Thu, 1 Feb 2007 14:24:49 -0800

>4395 (BCP 115); there's a lot of missing information that we need to

Sorry about that; I actually put together a provisional registration
some time ago, then decided against sending it, as there were still
some aspects of the URI scheme that were up in the air.  Then the
urn stuff seemed more urgent, and I lost track.  Mea culpa, mea culpa,
mea culpa maxima. 

As it stands, the registration template would look like this:

 URI scheme name.
    "lost" is requested

   Status.
      Permanent is requested

   URI scheme syntax.
     	
      LoST-URI = "lost:" host

     'host' is defined in Section 3.2.2 of RFC 3986 [7]
	
   URI scheme semantics.

      The "lost" scheme is intended to be used in order to identify
    the target of a LoST query, as described in draft-ietf-ecrit lost.
    Where the host portion of a the lost scheme is not IP address,
    the URI processor is expected to use U-NAPTR [12] using the
   U-NAPTR specification described below to obtain a URI
   (indicating host and protocol) for the applicable LoST service. 
   Current work describes the URI target derived from the
   U-NAPTR lookup as either HTTP or HTTPS, but this may be
   extended in the future to other URI schemes if other
   transports are defined.

   Encoding considerations.

     There are no special encoding considerations here, other than
     those set out in 3.2.2 .  The working group expects that a
     lost URI using a registered name will commonly be using
    the DNS, rather than one of the resolution implementations
    mentioned in 3.2.2 and strongly urges hose deploying LoST to follow the
    recommendation of 3.2.2 that: "URI producers should use names
   that conform to the DNS syntax, even when use of DNS is not immediately
   apparent, and should limit these names to no more than 255 characters in length"

   Applications/protocols that use this URI scheme name.

     A lost URI may be carried by any protocol that intends to notify
     the recipient that lost service is available at the specified host.
     Commonly, this will mean in configuration protocols, although
     it might occur in plain text or html as a reference.

   Interoperability considerations.

      No special considerations.

   Security considerations.
     
     The security considerations set out in RFC 3986 apply.  Additionally,
     because this scheme uses U-NAPTR to resolve non-IP address host names,
     the security considerations of RFC 3958 (which U-NAPTR extends) apply.

   Contact Person

   Ted Hardie, [email-masked]

   Change controller.

     The IESG, delegated to the ECRIT WG if still extant.

   References.

I will update the protocol document with this text, after incorporating
any further comments.

>would be different of course; you probably wouldn't need a new one,

There are two main reasons why HTTP is not being used as an application
protocol here.  The first is that overall architecture is intended to allow
the key pieces of lost to remain the same, even if deployment proves that
it would be more effective if deployed using a UDP-based transport, some
different TCP-based transport, or its own, dedicated transport.  The use
of u-naptr for resolution is intended, in particular, to allow this, even as
the authors and working group recognize that the quickest deployment path
is to re-use HTTP.  The second reason relates to HTTP's current deployment
characteristics; in many environments HTTP queries are intercepted for
proxy handling of various kinds.  Those interception proxies are a serious
concern for a protocol intended to deliver information about where to
target emergency calls.  They may, in the end, help, but the working group
wanted a way to distinguish the traffic and/or alter the underlying
protocol if that were not the case.
			regards,
				Ted Hardie