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

[Ted Hardie <hardie at qualcomm.com>]

At 3:29 PM -0500 2/1/07, Mark Baker wrote:
>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.

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, hardie at qualcomm.com

   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.

>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.

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



>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.
>
>On 2/1/07, Hannes Tschofenig <Hannes.Tschofenig at gmx.net> wrote:
>>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
>>Uri-review at ietf.org
>>https://www1.ietf.org/mailman/listinfo/uri-review
>>
>
>
>--
>Mark Baker.  Ottawa, Ontario, CANADA.         http://www.markbaker.ca
>Coactus; Web-inspired integration strategies  http://www.coactus.com
>
>_______________________________________________
>Uri-review mailing list
>Uri-review at ietf.org
>https://www1.ietf.org/mailman/listinfo/uri-review


_______________________________________________
Uri-review mailing list
Uri-review at ietf.org
https://www1.ietf.org/mailman/listinfo/uri-review