I've included my last call comments on sip-location-conveyance. Unfortunately,
this is a lengthy email.
The bulk of my comments are minor. The abstract, which is quite concise,
belies the enormous size of this document. I, like Hannes before me, believe
that this could be written for more succinctly than it is.
However, I am also of the opinion that we've been sitting on this document for
too long. Perhaps this document exemplifies the RAI woes. It needs to be
published, and I have very few substantial concerns with the technical content
of the document. At this stage, I would rather have a poor document published
than have to wait another year for a good document.
However, the items I've identified as issues need to be addressed.
==Issue: Articulate Geolocation header semantics
The most important thing that this document needs to define is the semantics of
the Geolocation header. Section 3 gets straight into the "how", but never
actually clearly states what the header means. A UA is supposed to infer
_something_ from the presence of a Geolocation header. The semantics are
unstated, which could lead to confusion.
The problem is compounded in Section 6.1 when the document talks about location
information for multiple targets in the one request.
Text along the lines of the following is necessary:
"The Geolocation header indicates a resource that includes the physical
location of the UA indicated in the From: header of the message."
Of course, this statement is both incorrect and incomplete. You need to
consider each of the SIP requests to arrive at a general framework for
understanding the semantics of the header. As it stands, the document provides
no basis for determining what the semantics of the header are in, for instance,
an INFO request.
Further to this, the use of Geolocation in a NOTIFY request needs to be made
very clear. NOTIFY in presence has well established semantics. In many
respects, Geolocation is not necessary for NOTIFY, particularly if it means
that there are special cases required in establishing a common semantic for the
header.
On the same issue, the following statement could be addressed for PUBLISH, but
is avoided with some decidedly weaselly words:
Discussing location using the PUBLISH request is out of scope
for this document since it is part of Presence, therefore, for
completeness, Table 1 shows PUBLISH is to support Location
Conveyance via this extension, but is not discussed further.
Further related, I think that there are unstated assumptions about use of the
entity attribute of the PIDF document. I don't think that this appropriately
considers the possibility that the PIDF could contain an unlinked pseudonym:
However, if location is already in a SIP request, a SIP server
SHOULD NOT add another LbyR that identifies the same target in the
PIDF-LO (in the <dm:device id> element) to the same request. This
will likely cause confusion at the Location Recipient as to which to
use.
I have been operating on the assumption that the binding of location to
identity was done in SIP. I can follow up with use cases and include more
discussion as necessary.
==Issue: What does Geolocation-Error 500 mean
I don't understand this error code.
I don't think that I could successfully distinguish this from 1XX errors,
despite the document claiming that the difference is simple (another value
judgement). It almost seems like a 4XX.
==Issue: Proxy insertion
I'd like to see the document answer this question: If a UAC doesn't understand
this document and the proxy inserts location for it, what behaviour is expected
from both proxy and UAC if a 424 response is received?
The proxy consumes the Geolocation-Error header and determines that it needs to
send again - but how does it do this? Does it alter the error code to force
the UAC to re-send the failed request? If so, how does it determine that
location is needed in the subsequent request? Or, does this scenario always
result in failure?
==Minor Technical Nits
Please reference RFC 3986 for URI ABNF. Note also that all specific URI ABNF
is a subset of the 3986 ABNF, so sip-URI, sips-URI, pres-URI and cid-url are
redundant (yes, this comment has been made and ignored previously).
What benefit does the following restriction provide?
Placement of the "routing-allowed" parameter, when
present, MUST be the last header value in the Geolocation header.
Requiring positional significance on header parameters only leads to more
complicated implementations. If location can be inserted along the path, and
that insertion must be at the end, insertion is quicker without having to first
remove this parameter and re-add it after.
Also on "routing-allowed", why is presence or absence of the tag used to
indicate yes and no, rather than requiring values?
Avoid making value-judgements, such as:
#1 - SIP Servers are not the best Sighters
Suggest changing the Geolocation-Error "code" parameter to be "text" to make
its usage clearer. What about i18n concerns on this parameter; does it need
language tags?
I don't have a means of interpreting Table 1 and Table 2. There is no legend
in RFC 3261. I apologise for singling this document out, but I generally don't
dig into SIP I-Ds in any great depth. No doubt there is some unstated
convention that is widely understood.
The examples still don't conform to RFC 5491.
Section 6.1: as established in geopriv-lbyr-requirements, an LS is the entity
that serves a location URI. Following on from that, the Location Generator
isn't involved in control of any sort.
I can't see how the following statement makes sense:
Use of self-signed certificates is inappropriate for use in
protecting a PIDF, as the sender does not have a secure identity of
the recipient.
Use (or not) of self-signed certificates generally leads to issues regarding
trust anchors, so this statement almost makes sense. However, I don't
understand what protection is being sought here.
If this statement is intended to address the issue where the UAC doesn't know
the ultimate recipient of the request, then the issue is different. In this
case, the issue is relates to whether data can be encrypted for the recipient.
I don't think that 2119 language is appropriate for the following statement:
The UAS is not REQUIRED to dereference the LbyR if
it does not want to (by configuration or user choice).
The same goes for the statement that follow this.
Is this a recommendation by stealth?
This document gives no guidance which SIP
request to use, but SIP MESSAGE is a viable choice.
If MESSAGE is the right way to indicate location, then say it. Or, don't make
any recommendation.
On multiple locations:
This document says nothing about what a Location Recipient does with
more than one 'good' locationValue in a request (i.e., which to
choose to use). This scenario MAY be addressed in a future effort.
This isn't a hard problem to solve. I don't see a need to defer this decision.
Pick an answer. If it turns out to be the wrong one, then that's ok, the
future effort can fix it. Better to pick one and be wrong than leave it
unspecified so that we get interoperability problems.
On the assumption that SIP is the only dereference protocol:
A proxy wishing to dereference an LbyR URI contained in a received
request will use the 'presence' event package in a SUBSCRIBE request
to the URI.
With statements like this, there is little point in allowing other protocols.
Section 6.3.2 refers to a proxy being subject to all the rules of a UAS, and
then references 6.2.1, which discusses geolocation-error generation:
For proxies that receive a SIP request that contains a location
error, either in a contained message body or after the proxy does a
dereference of the LbyR URI, all the rules applicable to a UAS apply
here (see Section 6.2.1.), since in this case, the proxy is
considered a Location Recipient. Therefore, there is no reason to
restate them here, and potentially have the two sections be
inconsistent.
This is confusing. Does this relate to processing of the request? Generation
of the error (as implied by the reference). Or is this a privacy thing
(implied by the use of the GEOPRIV term of Location Recipient)? If it does
relate to consumption of location information and generation of 424 or
Geolocation-Error headers, then it might make sense to put all information
regarding this behaviour in a separate section.
The large paragraph on Section 8 Page 38 seems to be a rehash of the issues
discussed in draft-ietf-geopriv-sip-lo-retransmission and
draft-ietf-geopriv-lbyr-requirements. As it stands, the discussion on the
difficulties associated with deploying authentication are interesting, biased
and not relevant for this document. Better to add an informational reference
and be done.
Small change to the following to allow for different authorization models:
Accordingly, possession of the reference should be considered
equivalent to possession of the value, and the reference should be
treated with the same degree of care as the value.
s/Accordingly/Unless a location reference is known to be public/
==Editorial
This document uses and invents terminology that is inconsistent with GEOPRIV
documents.
This is a difficult document to read and review. The longer sections lack
structure and use very long paragraphs with lots of symbols, terminology and
parenthetical statements.
Avoid using ABNF names in text where English would suffice. The weakness in
using this approach is revealed when you pluralise these. locationValue and
locationErrorValue are used extensively in this manner.
Page 8: what makes the header parameters "independent"? A roguish disposition
with a natural disrespect for authority?
Some sections could really benefit from sub-sections. The current document has
a stream-of-consciousness quality that makes it difficult to quickly find
relevant text. At a minimum, sub-sections for each header parameter would be a
great help.
A degree of bias is shown in Section 6.1, avoiding mention of HELD. I'm
demonstrating my own bias by making the comment, but I don't think that the
comment is any less valid for it.
Section 5.1 contains text about location by reference that is redundant given
the subject of Section 5.2.
--Martin
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip
