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

["James M. Polk" <[e-mail]>]

Martin

in-line

At 12:55 AM 7/13/2010, Thomson, Martin wrote:
>Firstly, the good:
>
>The simplifications are a great 
>improvement.  The document is more accessible 
>and readable as a result.  The mechanism is fundamentally simpler.

glad you agree


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

it has always been in Conveyance, but might have been lost in the clutter.


>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.

I believe we can have a location URI in the 
presence document. But you're right, we don't 
want one locationValue identifying a PIDF-LO and 
another locationValue indicating a location URI.


>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.

ok...


>Jon's original response to this was to push the 
>composition problem to the PIDF-LO.  That could be done,

that is what's done, there is no 'could'. The 
text surrounding Figure 4 states this, and the 
example in 5.2 explains this is the example 
albeit showing two composed values from different sources.

>but it needs more specification.
>
>Reaching some sort of consensus on the solution 
>to this problem before this work is finished is important.

agreed


>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 errors are in categories, of which, only one 
category has more than one error code(the 3XX category about permissions).


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

what would justify it?

the purpose of an option-tag is the ability to 
indicate support for an extension (whether 
optional or required), and to respond with 
whether or not an extension is supported or 
unsupported. This indication can be quite 
important for communicating SIP elements to 
understand support for (or not). I'm confused...


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

how so?

It is already covered by the geopriv-filters 
reference. I do not believe anything more is necessary.


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

I'll talk to my co-authors about this, as they 
are the ones limiting the number of examples  ;-)


>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.

this might be a good point. I'll talk to my 
co-authors about breaking up section 3 into sub-sections (1 per Figure).


>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 is quite possible. This was a bit cobbled together.


>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.

it's certainly known inside the voice/telephony world.

>More amusing was the idea that your 
>characterisation of a person was as a "non-IP device".

many readers misunderstand when talking about 
Alice, it's one of her electronic devices that 
SIP communicates with, not her directly.

Thanks for reading this so quickly and providing comments (seriously)

James


>--Martin
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of James M. Polk
> > Sent: Tuesday, 13 July 2010 9:55 AM
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore