Re: [sipcore] location-conveyance-03 just submitted

Firstly, the good:

The simplifications are a great improvement.  The document is more accessible and readable as a result.  The mechanism is fundamentally simpler.

Content indirection has some interesting benefits.  It's a good idea.

I have some comments that includes one major issue.

The major issue:

The limitation to _one_ location value has undeniable benefits.  It also prevents the conveyance of location value and reference together.

draft-ietf-ecrit-rough-loc describes one use case that this affects.  Brian (your other co-author) should be able to apprise you of the consequences this has to the NENA use cases.

Jon's original response to this was to push the composition problem to the PIDF-LO.  That could be done, but it needs more specification.

Reaching some sort of consensus on the solution to this problem before this work is finished is important.

Minor issues:

The structure of the Geolocation-Error header description is a little odd.  It seems that you are trying to describe *classes* of error and specific errors at the same time.  Separating these concerns might make this easier to explain and understand.

The draft doesn’t really justify the existence of the "geolocation" option tag.

Section 4.6 should reference draft-ietf-geopriv-deref-protocol.

Section 5 should show an example use of content indirection for a location URI.

Just a few nits:

Overall, the structure is greatly improved, but when you see references in the form "in section 3 (below Figure 4)", you have a need for more sub-sections.

The examples in Section 5 are not schema-valid - c.f. RFC 4119 errata #1771
  <http://www.rfc-editor.org/errata_search.php?rfc=4119>

This, in the introduction, doesn't read well:

  a non-IP device (a person or a black phone)

"black phone" is a little jargon-y.  More amusing was the idea that your characterisation of a person was as a "non-IP device".

--Martin

> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> Behalf Of James M. Polk
> Sent: Tuesday, 13 July 2010 9:55 AM
> To: sipcore@ietf.org
> Subject: [sipcore] location-conveyance-03 just submitted
> 
> SIPCORE
> 
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-
> conveyance-03.txt
> 
> This version is a fairly radical departure from previous versions of
> the (long standing) effort.  This time the doc didn't grow...
> 
> We added Jon Peterson as a co-author, and he helped in Anaheim
> propose a significantly less complex way of specifying location
> conveyance for SIP. More than 95% of the doc has been rewritten by
> Jon and I, with a net result of 27 less pages of text (52 to 25 now).
> 
> We took out the terms and concepts of following parameters:
> 
> - inserter
> - inserted-by
> - used-for-routing
> - host-id
> - node-id
> 
> as well as limiting the number of locationValues to *ONE*, in a SIP
> request.
> 
> We removed the ability for SIP intermediaries to add location along
> the way unbeknownst to the UAC (with one infrequently used
> exception). In this way, location errors are only end-to-end, so
> there is no need to identify which entity added location to make sure
> the right entity reacted the right way when an error was caused by
> the location they inserted, and not that of another entity's inserted
> location (which is all very confusing).
> 
> We added the ability for a SIP intermediary to augment a location
> with what the UAC should send in a subsequent request, and the
> ability to verify this augmentation is present before successfully
> processing that request. This is in line with both RFCs 4479 and 5491.
> 
> Comments are appreciated
> 
> James
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore