The following are the notes of the conference call held on location
conveyance held last week. Comments are welcome, but please address any
comments on anything but accuracy to a separate thread (i.e. change the
subject of your email).
These will also be posted on the review site in due course.
Regards
Keith
Notes of review team call on WGLC comments on draft-ietf-sip-location-
conveyance-07 held on 25th April 2007
1) Roll call
The following participated in the call.
Richard Barnes
Keith Drage (moderator and scribe)
Mark Lindsey
James Polk (document editor)
Brian Rosen (document editor)
Henning Schulzrinne
Hannes Tschofenig
Joszef Varga
2) Agenda bash
No changes.
Keith noted that the key questions mentioned in the agenda were only his
view of
the comments made, in order to give some direction to the discussion,
and people
should refer to the comment in the case of dispute over the meaning.
3) Methodology
Keith outlined the methodology of the review calls, which was:
- to give a first discussion of key points;
- if new comments arise from discussion, they should be identified
verbally
and ensure they are documented;
- comments discussed can have resolution agreed in the call, or
defer, or
take to list, or leave to authors to make a judgement.
Further the review team should try and represent previous consensus of
the
working group (SIP or GEOPRIV) as appropriate. Should regard themselves
as
acting on behalf of the working group.
4)
Issues relating to multiple locations
Comments: 2, 3, (66), 78, 94, 96, 153, 164
Key questions:
- Do we want multiple locations?
- If there are multiple locations, which should be used?
- If a 424 is returned, which location does it relate to?
- Which location does the warning refer to?
- In what circumstances can multiple locations cause a call to
fail - or can
one be used and ignore the rest?
- If you have a location by value, do you need to also resolve any
location
by reference?
- Anything different for multiple locations in responses?
After discussion it was agreed that the following would be recommended.
This
summary would be taken to the list by Keith for a WG consensus call:
- location conveyance should support the delivery of multiple
locations;
- the document will make no recommendations as to how the
recipient chooses
which location to use. This is regarded as specific to the using
application,
and therefore beyond the scope of the protocol extension;
- the recipient should attempt to make use of all the locations
given, and
should only respond with a 424 response if it is unable to use any of
those
locations. This includes resolving all and any locations by reference;
- as a result of the above, any 424 response is a collective
statement about
all the locations given in the request rather than any specific location
in the
request.
Action 1/1: Keith to take above list to WG for consensus call, as
direction to
the editors.
It was also discussed if we should agreed that if a location is already
present
in a request, one should not add another, as it is not possible to
resolve which
location sender the 424 response relates to. As this may not be a
restriction
based on later discussion of improvements to the error handling, we will
hold
this decision until we have resolution of the error handling issues.
There was discussion of Warning header meanings in regard to multiple
locations
in error. It was considered that there needs to be some form of
correlation
between Warning headers and specific locations. See later in the
discussion for
further details of resolution process.
The issues of multiple locations in responses was deferred to later in
the
meeting under the "location in responses" agenda point.
5) Security issues
Comments: 21, 27, 117A, 129C, 129D, 168, 181A, 181B, 137
Key questions:
- Any issues with mandating multipart MIME?
- Signing versus encryption issues?
- Document security issues when retrieving location by reference?
- Are mechanisms different for LbyrR and LbyV?
- Is security considerations section adequate?
- Are self signed certificates out of scope?
- Is mandating a retry without TLS in scope?
The review team agreed that the extension would assume that conformant
implementations supported multipart MIME. This was seen as an
implementation
problem of existing specifications, rather than a problem with the
specifications themselves. Discussion identified that the real problem
was with
gateways which would send an error message to requests containing
multipart MIME.
As regards the signing versus encryption, agreed that clarification was
required
in the document, but this was a matter of an editorial pass.
The security for dereferencing related to two issues:
- security of the reference. Part of this centred around the issue
of
whether the reference contained the identity of the user sending the
information.
It was agreed that the reference is just a URL, and therefore does not
consititute an identity.
- it is known limitation that when a proxy inserts a location by
reference,
that the UA user is not a rule maker (RFC 3693 specifies the rulemaker).
There
is some suitable text in the RELO document that covers the same issue.
Hannes is
going to send text to the review team
Action 1/2: Hannes to send text to editor's and review team covering
this issue
- security of the dereferencing procedure. This was regarded as
being out of
scope, as the dereferencing protocol was also out of scope.
It is also a known limitation that existing mechanisms do not allow a UA
to
request proxy implementation. This is believed to be a separable
problem.
Need to spell out that need same protection for location by value and
location
by reference in the security considerations. Hanne's point - wants more
text
saying TLS is used and "we really mean it". Brian will offer text here.
Action 1/3: Brian to provide text relating to the usage of TLS.
In regard to the adequacy of the security considerations Hannes had
agreed to
suggest some text. It was noted that the philosophy of the document was
to put
the RFC 2119 language regarding security in the main procedures, and
merely
comment on the security provided in the security considerations section.
Action 1/4: Hannes to send text (can be just key points to be covered)
to
editor's and review team covering this issue
In regard to the self-signed certificates issue (comment 137) it was
agreed that
the appropriate document to cover this issue in regard to location was
draft-
ietf-sip-certs. It was proposed therefore to remove all text in the
document
relating to self-signed certifications.
Action 1/5: Keith to post to list stating that the agreement is to
remove and
asking for WG consensus.
Action 1/6: Keith to send mail to Cullen Jenning / Jason Fischl
regarding the
need of draft-ietf-sip-certs to provide any documentation on this issue.
The issue relating to retry without TLS if the request fails with TLS on
an
emergency call was dealt with as part of a general consideration of all
emergency call issues in the next agenda item.
6) Emergency issues
Comments: 129B, 167A, 169
Key questions:
Should we cover emergency at all in this document?
It was agreed that section 6 and therefore all text relating to
emergency calls
should be removed. It was agreed that it was the responsibility of ECRIT
to
apply location-conveyance to emergency calling applications.
Action 1/7: Keith to send mail to list asking for WG consensus to
agreement to
remove emergency call text from location-conveyance.
Noted that James was not wonderfully happy with this, and may reraise
the
discussion once he sees the impact of the decision on the text.
7) Response usage
Comments: 29, 150
Key questions:
- Is location allowed in responses, and if so, what are the
procedures for
error handling?
- What are the associated Require: and Supported: procedures?
It was identified that if location was allowed in responses, we would
have two
possible semantics:
- the conveyance of location information about the UAS;
- the echoing of location information about the UAC for the
purpose of
loopback testing.
It was agreed that we can only support one of these; that location
conveyance in
the reverse direction can always be covered by an in-dialog request
initiated in
the reverse direction, and that the loopback testing is a needed
procedure. It
was therefore agreed that:
- location-conveyance in responses to give location of the UAS
would be
specifically removed from the document. This should be done by a
subsequent
request in the opposite direction.
- that location in responses would relate to location of UAC for
test, but
this would be a new procedure. This would need to be considered by the
WG in a
list discussion.
Action 1/8: Brian to post proposed procedures to list for covering the
above,
and obtain WG consensus to this proposal.
Removing location conveyance in responses probably simplifies the needed
text
for Supported and Require headers. James will add text that allows the
geolocation option-tag in a Supported header. A Require header in a
response
should never include geolocation.
8) Error handling issues
Comments: 30, 79, 84, 85, 110, 147
Key questions:
- Dialog usage - does 424 clear the dialog or just the specific
usage?
- Can Warning only appear in 424?
- Do we need all the warnings given?
- Do we need 701?
- What mechanism should we use to indicate URL schemes?
- Do we always return an error, or can we just ignore a problem?
In regard to the dialog usage, it was agreed that 424 just ends the
usage in a
response to an in-dialog request, and that the transation is retained.
Text will
be inserted to reflect this.
In regard to the remainder of the issues, there was a discussion that
resulted
in a view that the existing error mechanisms were insufficient. This
centred
around the following points:
- difficulties with correlation already identified earlier in the
call
- may want to be able to indicate problems with a location when
the call can
still proceed (e.g. emergency calls should still be addressed to a PSAP
even if
the location cannot be used) and therefore no 424 is ever sent.
Henning did not like the whole Warning header idea any more as a result
of this
discussion, and suggested a new Location-Error header that gives
detailed header
values (to be used in 424 and 200). This could be along the lines of
the
History-Info header. Suggested an identity tag to tell the UAC which
error
applies to which location in the request (when more than one location
was
inserted in the request - perhaps by a proxy in which the UAC doesn't
know the
proxy did).
Rather than design on the fly as part of the resolution discussion, this
agenda
item was parked at this point. Henning agreed to elaborate by email, and
from
that point we would decide whether the way forward to resolve this was
by a new
i-d documenting the proposal, followed by WG consensus call, or by an
email
proposal to the WG list.
Action 1/9: Henning to draft strawman proposal and initiate discussion
among
review team in order to get the concepts correct, prior to SIP WG
discussion.
9) Method usage
Comments: 62, 69, 73, 74
Key questions:
- INFO?
- Mid call location updates use what mechanism?
- REFER?
- PUBLISH?
- BYE?
For location update in the middle of an INVITE dialog, it was agreed
that UPDATE
was the correct method to use, unless there was a reason to send to send
a
reINVITE for some other purpose at the same time as this occurred. Text
in the
document already says use UPDATE for this purpose.
Given that the only function of putting Geolocation in INFO would be for
the
same purpose, it was agreed that the Geolocation header would not be
specified
for the INFO method.
For PUBLISH it was agreed that Geolocation would be allowed in this
method, but
text would clearly state that any usage was not to duplicate mechanisms
where
the PIDF-LO should appear in the event package carried by PUBLISH. No
use case
identified at moment that fulfils this constraint, but this should not
preclude
the availability of a generic protocol mechanism if such a use case does
appear
in the future.
The same consideration about no use case, but not precluding the
availability of
a generic protocol mechanism if such a use case does appear in the
future,
applied to the other methods listed in the key questions. Therefore
Geolocation
will be allowed in these methods. This also includes PRACK, but does not
include
ACK and CANCEL, as these are not always end-to-end.
10) Body issues
Comments: 159
Key questions:
- What additional information is needed to describe bodies?
The issue here is what happens if the Content-Type of the body is
understood,
but there is no recognisable Geolocation header (corrupt or removed by
some
intermediate entity). Agreed that the Content-Type is sufficient
description of
a location, and therefore the location could be used by a UAS when
conforming to
this document (SHOULD strength). However the UAC procedure will remain
MUST send
the Geolocation header.
11) PIDF-LO usage
Comments: 121, 153A
Key questions:
Point usage deprecated?
Proxy usage - what can proxy say about this location - is this
in scope of
this document or does GEOPRIV need to handle it?
Main issues discussed here was on whether the examples should conform to
RFC
4119 (as they currently do in showing point usage) or should reflect
later
updates still formally with the working group. There was discussion, but
no
agreement, on whether we could remove the PIDF-LO from the example
altogether
(replace content by an ellipsis or some such device) as this part of the
example
does not relate to any requirements in this SIP extension.
Remaining issues in this agenda item were not discussed due to lack of
time.
12) URI issues
Comments: 7, 64
Key questions:
Issues in this agenda item were not discussed due to lack of time.
13) Routeing query allowed issues
Comments: 11
Key questions:
Issues in this agenda item were not discussed due to lack of time.
14) Retransmission allowed issues
Comments: 61A
Key questions:
Is mechanism needed?
Issues in this agenda item were not discussed due to lack of time.
15) Terminology usage
Comments: 1, 19, 43A, 101A, 116B, 129A
Key questions
- Are "by value" and "by reference" the appropriate terms?
- Is LbyR a using protocol?
- Are there any circumstances where we need to talk about LIS
rather than LS?
Issues in this agenda item were not discussed due to lack of time.
16) Pull mechanisms
Comments: 25, 144A
Key questions:
Are the mentioned pull mechanism valid, given that we don't
cover them at
all?
Issues in this agenda item were not discussed due to lack of time.
As we did not complete, it was agreed to hold another review call on
Tuesday May
1st at 10:00 - 12:00 Eastern. Keith indicated that the same bridge
details would
apply.
James agreed to provide a preliminary update of the draft in time for
the next
call.
_______________________________________________
Sip mailing list https://www1.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
