Subject: [Ecrit] WG: DISCUSS: draft-ietf-ecrit-lost

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 21 Feb 2008 08:25:56 +0100

FYI 

-----Ursprüngliche Nachricht-----
Von: ext Lisa Dusseault [mailto:[email-masked]] 
Gesendet: Mittwoch, 20. Februar 2008 23:49
An: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Betreff: DISCUSS: draft-ietf-ecrit-lost 

Discuss:

1. Redirects

The section on redirect (13.3) is shockingly short.   Are redirects permanent or temporary?  Should other servers change their listings when seeing a redirect?  Redirects have caused interoperability problems in HTTP; perhaps a little deeper review of the need for the functionality would help here.

I'm inferring from section 14. that HTTP redirects MUST be supported by clients as well as LoST redirects.  Can that be made a normative requirement?

2a.  Open-ended URI types
I'd like to see more guidance on what URIs are returned.  The risk that the LoST server will return a URI that can't be used by the seeker is a bad risk to take when it comes to emergency services.

 - Add "tel" URI examples to the examples; Explain that in the worst case of not being able to use the URI types presented, seekers that have user interfaces should present the telephone number to the user; recommend that phone numbers be provided this way as fallbacks for emergency services
 - limit the types used: no data or mailto URIs; better yet have a registry of types that *can* be used
 - In the case of SIP URIs, what kind of contact can be made?  Can this URI get a human voice, a voice mailbox, a presentity or other?  
 - Differentiate between contact and resource URIs?  A resource URI obtains something static, a contact URI may be able to begin a conversation...

I'd like a little discussion of the requirement that each URI scheme may appear only once.  That seems to prevent some fairly common use cases like providing one number for voice mail and one number to reach an operator.  The proliferation of http URIs makes this even worse -- many different kinds of services can be hosted on http URIs.  The Atom link rel provides an example of how one might deal with this problem.

2b. IRIs

Is support for IRIs explicitly not desired?

2c. URI security/privacy

I assume both LoST URIs (found in NAPTR) and service URIs can contain anything allowed by the URI scheme; long paths, query elements, anchor points. I can see a slight privacy issue here, because the URIs can contain tokens allowing communication from the LoST server that provided the URI to the service hosting that URI.

This document doesn't talk about preserving URIs end-to-end.  What if a LoST resolver were to "helpfully" try to change URIs before passing them on to seekers?  Is there some other document that covers this?

3.  Overlooked HTTP features.

A number of features that are commonly overlooked when using HTTP this way are not mentioned.  I like that HTTP caching is disabled but it looks like there's a cut-and-paste error in that part of the spec:

  The HTTP request MUST use the Cache-Control response
   directive "no-cache" to HTTP-level "caching even by caches that have
   been configured to return stale responses to client requests."

For the rest I suggest adding: 

"LoST servers MUST handle the Expect header, conditional headers and Content-* headers on requests according to HTTP requirements (possibly by failing the request).  They MUST also handle OPTIONS and HEAD and GET requests even if it's by responding with canned 200 responses.  

"LoST clients MUST include a Host header and MUST handle all possible HTTP response codes. 

"Both LoST clients and servers MUST handle chunked transfer-encoded message bodies."

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