Subject: [Ecrit] Some comments on draft-ietf-ecrit-lost-01.txt

From: Leslie Daigle <[email-masked]>
Date: Tue, 26 Sep 2006 19:35:13 -0400

I'm not sure I'm tracking this section:

> 4.  Resolving Service URNs Using LoST
> 
>    If a LoST URL contains a host name rather than an IP address, clients
>    need to perform an U-NAPTR [17] lookup to obtain a DNS A record and
>    IP address.  These records map the 'host' part of the LoST URL to one
>    or more URLs indicating the protocol to carry the LoST request.  In
>    this document, only the HTTP and HTTPS URL schemes are defined.  Note
>    that the HTTP URL can be any valid HTTP URL, including those
>    containing path elements.
> 
>    Here is an example:
> 
>    example.com.
> 
>    IN NAPTR 100  10   "u"    "LoST:https"
>         "!*.!https://lostserver.example.com/secure!"  ""
> 
>    IN NAPTR 200  10   "u"    "LoST:http"
>         "!*.!http://lostserver.example.com!"  ""
> 
> 

The text talks about using U-NAPTR to get A record/IP addresses --
and yet the whole POINT of U-NAPTR is to allow the possibility
of returning URIs, which is what the example shows, anyway..?

And is that section title a carryover from a previous version,
because I don't see how this has to do with Service URNs?

So maybe that should be something like:

4.  Resolving LoST URLs

    If a LoST URL contains a host name rather than an IP address, clients
    need to use U-NAPTR [17] using the U-NAPTR specification
    described below  to obtain a URI (indicating host and protocol)
    for the applicable LoST service.   In
    this document, only the HTTP and HTTPS URL schemes are defined.  Note
    that the HTTP URL can be any valid HTTP URL, including those
    containing path elements.

    Here is an example:  for lost:example.com

    example.com.

    IN NAPTR 100  10   "u"    "LoST:https"
         "!*.!https://lostserver.example.com/secure!"  ""

    IN NAPTR 200  10   "u"    "LoST:http"
         "!*.!http://lostserver.example.com!"  ""

And then you'd need a separate section defining the U-NAPTR application
(which application service(s) is(are) being defined or is(are)
applicable, and ditto for application protocols).

Then this section

> 9.  LoST Transport
> 
>    LoST needs an underlying protocol transport mechanisms to carry
>    requests and responses.  This document defines the use of LoST over
>    HTTP and HTTP-over-TLS; other mechanisms are left to future
>    documents.  The available transport mechanisms are indicated in the
>    LoST U-NAPTR DNS resource record.  In protocols that support content
>    type indication, LoST uses the media type application/lost+xml.
> 
>    When using HTTP [14] and HTTP-over-TLS [15], LoST requests use the
>    HTTP POST method.  All HTTP responses are applicable.  The HTTP URL
>    is derived from the LoST URL via U-NAPTR translation, as discussed in
>    Section 4.

needs some tweaking  -- there is no such thing as a "LoST U-NAPTR DNS
resource record".  Perhaps, instead:

9.  LoST Transport

    LoST needs an underlying protocol transport mechanisms to carry
    requests and responses.  This document defines the use of LoST over
    HTTP and HTTP-over-TLS; other mechanisms are left to future
    documents.  The available transport mechanisms are determined
    through the use of the LoST U-NAPTR application.  In protocols that 
support content
    type indication, LoST uses the media type application/lost+xml.

    When using HTTP [14] and HTTP-over-TLS [15], LoST requests use the
    HTTP POST method.  All HTTP responses are applicable.  The HTTP URL
    is derived from the LoST URL via U-NAPTR application, as discussed in
    Section 4.

And then I wondered if this reference was still right:

>    A LoST service may also be represented by multiple LoST servers,
>    either grouped together or at multiple network locations.  Using
>    S-NAPTR [24], clients may be given a list of multiple servers to
>    which queries can be sent for a single service.

I.e., is that still S-NAPTR, or is it now U-NAPTR, or?

Leslie.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 26 Sep 2006 21:55:01 -0400

> of returning URIs, which is what the example shows, anyway..?

Indeed; the section was hastily cut-and-pasted, and thus is best  
taken with a large grain of salt.

> applicable, and ditto for application protocols).

Agreed.

>    through the use of the LoST U-NAPTR application.  In protocols  
> that support content

This is indeed more precise.

> I.e., is that still S-NAPTR, or is it now U-NAPTR, or?

That whole section is obsolete. I've given Hannes a set of edits that  
get rid of it.