Subject: [Sip] Review: sip-location-conveyance-07.txt

From: Shida Schubert <[email-masked]>
Date: Sat, 10 Mar 2007 20:07:31 -0800

Draft:  draft-ietf-sip-location-conveyance-07
Reviewer: Shida Schubert
Review Date: 10 Mar 07

Summary:
----------------------------------------
 Some clarifications are needed for it to progress further but 
generally speaking draft looks pretty solid.

GENERAL QUESTIONS/CLARIFICATION REQUESTS
--------------------------------------------------------------
1. Dealing with multiple location information.
   As geolocation can be populated with various location information
  some provided by UA, some provided by intermediaries, it may be
  useful for there to be an ability where UA can express preference
  among location information it provides.
 
   Currently the spec doesn't say anything about how UAS/server selects
  the location to be parsed when there are multiple location information.
 
   Related to this, section with UAS behavior should elaborate on when
  424 is to be returned. Is it when one of the many location information
  was problematic? Or is it when all of which UAS tried failed? Obviously
  there will be variation but some guidelines may be helpful.
 
   Also, desirable behavior of UAS/proxy handling message with multiple
  location information may be desirable.
 
    Now if we don't want to deal with multiple location information,
  it may be better to change the relevant text from MAY to NOT RECOMMENDED.

2. Section 3.4.6 Warning code 706 Conflicting Locations Supplied
 > I understand its use, but considering proxy may add Geolocation
   header with reference URI, it's out of UA's control to restrict
   the number of location to be conveyed unless...
    1. UA can tell the proxy not to add location
    2. UA can find out if location was added by other entity in which
       case it can omit adding location itself and have the proxy add
       location or route a call through other proxy which may not add
       location.
      
3. General problem with debugging the warning code and 424 response.
 > Because the location URI can be added by proxy, when warning code
   is sent, it would be useful to include the
   location URI (cid, sips, pres etc.) that triggered the error/warning.
   This would allow UA to see if location was added by intermediary,
   which location was malformed etc.

4. Section 5.2, 5th paragraph, 2nd sentence.
  > "but all MUST point at the same position on the earth."
   > This is not something one can enforce, I don't think UA generally has
     facility to translate geo<->civic. MUST strength seems a bit too 
strong
     here. May be SHOULD?  
     
5. Section 3.5, 2nd paragraph, 2nd sentence.
 > Semantics of Require header with "geolocation" option tag is unlear.

   > Section 3.5 reads as if it is to request UAS to send back location but
     Section 5.2 merely implies that UAS understands the specification.
     I believe there needs to be consistency with the semantic.

6. Section 5.2, 3rd paragraph, 1st sentence.
 > Do we want UAS to return an error even when location information is
   irrelevant to the dialog in question? Imagine a scenario where Alice's
   phone is set to always convey location info to her buddies even when the
   call has nothing to do with location. With the current spec simple call
   which has no business with location would fail if for example Alice's
   presence server is down.. Again there is no MUST or SHOULD on this
   paragraph so may be it's OK.

6. Section 5.3, last paragraph.

 > 424 (Bad Location) when location based query is not permitted seems a 
bit
   odd. It's really not location that's bad, but it's the associated policy
   that prohibits the server from doing what it needs to do.

 > I didn't see any appropriate warning code for this but can we provide  
   more helpful error to the client for this scenario?

7. Section 5.3.2
  > Proxy sending error when there is a location specific problem seems
    a bit problematic to me. I think you need to be clear about when 
this is
    appropriate. (malformed XML, can't decipher etc.) I think we want to
    prevent a case where proxy can't process the location information 
properly
    but UAS can. The only time proxy should return an error is if it is
    certain the location specific problem it sees is also problematic to
    the UAS. Furthermore, we don't want proxy not even doing location based
    routing to hinder a call just because it sees problem with location.

NITS
-------------------------------------------------------------
1. Section 1, 1nd paragraph, 3rd sentence.
 > The recipient of the location is not UAS alone as noted in the 2nd
   paragraph of this section, so you may want to say server or
   UAS & proxy rather than UAS alone.
 
2. Section 1, 3rd paragraph, 2nd sentence.
 > I think you mean "target" where the text says thing.
 
 OLD:
  A PIDF-LO is an XML Schema specifically for carrying geographic
  location of a thing.
 NEW:
  A PIDF-LO is an XML Schema specifically for carrying geographic
  location of a target.

3. Section 3.1 paragraph 1, 2nd sentence
 > Missing a closing bracket.
 
 OLD:
  The Geolocation header contains either a URI which may be a "cid:" URI
  (Content Identification, per [RFC2392]
 
 NEW:
  The Geolocation header contains either a URI which may be a "cid:" URI
  (Content Identification, per [RFC2392])
 
4. Section 3.2, paragraph 1, 1st sentence
 > It reads like the spec creates a new IANA registry.. IANA consideration
   covers all of which has to do with IANA, so I think all you have to say
   here is that the spec defines a new SIP header: Geolocation.
 
5. Section 3.2, paragraph 1, 2nd sentence
 > The Geolocation heade MUST contain one of two types of URIs is misleading
   I believe what you want to say is "at least one of two types of URIs"
   
   OLD:
    The Geolocation header contains either a URI which may be a "cid:" URI
    (Content Identification, per [RFC2392]
 
   NEW:
    The Geolocation header contains either a URI which may be a "cid:" URI
    (Content Identification, per [RFC2392]

6. Section3.2, paragraph before the table, last sentence.
   > "is" is missing.

   OLD:
    Discussing location using the PUBLISH
    Request Method out of scope for this document.

   NEW:
    Discussing location using the PUBLISH
    Request Method is out of scope for this document.

7. Section 3.2, 2nd last paragraph, 2nd sentence.
   > Confusing, needs to clarify that proxy is not allowed to
     modify the pre-existing URI values and associated parameters.

  OLD:
    A proxy MAY add the Geolocation header, but MUST
    NOT modify the contents of an existing Geolocation header.

  NEW:
    A proxy MAY add the Geolocation header, but MUST
    NOT modify any pre-existing URI values and its associated parameters
    of an existing Geolocation header.
    
8. Section 3.2, 2nd last paragraph, last sentence.
   > location-by-reference URI not location-by-reference.
     
  OLD:
    Therefore, a Geolocation header added by a proxy MUST specify
   location-by-reference.
   
  NEW:
    Therefore, a Geolocation header added by a proxy MUST specify
   location-by-reference URI.
   
9. Section 3.4.5
  > I believe this warning code is appropriate when PIDF fetched via
    SUB/NOT doesn't contain the LO portion.   

10. Section 3.6, 1st paragraph, 1st sentence.
  > I think what you are trying to say is taht, when Geolocation header is
    used to include a location-by-reference URI, sip, sips or pres URI 
SHOULD
    be used. Isnt' it? Right now, it reads like when Geolocation header is
    set, URI with one of the scheme should be set..
    
11. SEction 5, 1st paragraph, 3rd sentence.
  > term opposite UA sounds a bit odd.
 
   OLD:
    SIP endpoints SHOULD implement S/MIME to encrypt
   the PIDF-LO message body (part) end-to-end when the intended
   recipient is the opposite UA.
   
   NEW:
    SIP endpoints SHOULD implement S/MIME to encrypt
   the PIDF-LO message body (part) end-to-end when the intended
   recipient is another UA.
 
12. Section 5, 1st paragraph, last sentence
  > Unclear whether the target of TLS is the URI contained in the
    Geolocation header or the signalling path which message holding
    the header is conveyed.
    
13. Section 5, 2nd paragraph, last sentence.
  > "does" or "to" is missing.
    OLD:
     When using location-by-reference, it is
     RECOMMENDED that the URI not contain any identifying information
     (for example use [email-masked] rather than
      [email-masked])
   
    NEW:
     When using location-by-reference, it is
     RECOMMENDED that the URI (does|to) not contain any identifying 
information
     (for example use [email-masked] rather than
     [email-masked])

14. Section 5.1, 2nd paragraph
 > The terminology for Geolocation values seem to be inconsistent 
through out the
   document. It would be nice to have consistency for the type of URI 
used in
   Geolocation value. May be by-value URI and by-reference URI?
 
15. Section 5.1, 2nd last paragraph
 > "new Warning code" sounds like warning code yet to be defined. If you 
mean
    the warning code defined in the draft, it's better to be explicit 
about it.
    
16. Section 5.2, 2nd paragraph, 1st sentence.
 > "to" is missing
 
    OLD:
     A Require header with the geolocation option tag indicates the
     UAC is requiring the UAS understand this extension or else send an
     error response.
     
    NEW:
      A Require header with the geolocation option tag indicates the
   UAC is requiring the UAS to understand this extension or else send an
   error response.  
   
17. Section 5.3, last paragraph.
 > "retransmission-allowed" and "routing-query-allowed" is an element in 
the
 PIDF-LO but it's only mentioned in the beginning of the draft. It may 
be nice
 to mention it again here.

Regards
  Shida

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip