>Hi James,
>
>~snip~
>
> >>So, why cannot we re-use these error codes?
> >
> >I think we need to agree on what errors need to be sent, then someone
> >(you, I presume) will write that into the draft. This can start
> >simply by looking at the list above and see if there are other errors
> >that are needed *or* are already in Conveyance.
> >
> >For example, "locationUnknown" will likely be known when the
> >SUBSCRIBE is received, meaning this can be a SIP level error, and
> >isn't necessary in XML (which keeps it simple).
>
>Might sound simple from a protocol document writer but quite likely not
>for an implementer since this is a layer violation.
I don't believe this is a layer violation at all.
If I subscribe to a Nokia LS for your location, the SIP SUBSCRIBE
will either be accepted or rejected. If it is accepted (200 OK),
then there is an expectation that this Nokia LS has your location, or
can get it. SIP rules state that there is an immediate NOTIFY sent to
me from the Nokia LS with the current status of the query for your
location. If it has your location, this first NOTIFY will send that
to me. If not, a subsequent NOTIFY will contain your PIDF-LO.
However, if the Nokia LS knows it doesn't know your location, and/or
knows it will never know your location - it will either blanket
reject my subscription request (mostly based on policy), or with a
legitimate reason why (i.e., because it doesn't know your
location). This will occur in the response to my SUBSCRIBE, which
won't be a 200 OK (ever!) - because that 200 OK would mean that the
subscription was accepted even knowing it cannot ever fulfill the
subscription. The response would be a 4XX level rejection message -
likely containing a GeolocationError header value, containing a error
code indicating your location was not known.
> >
> >I don't understand the difference between "locationUnknown" and
> >"notLocatable" from the list above, other than "'''MUST NOT make
> >further attempts to retrieve LI from this LIS'. The difference
> >between these two appears to also be covered by the current error
> >codes in Conveyance - so they are clearly redundant, and therefore
> >not necessary - right?
>
>This is indeed the difference between the two. If it was acceptable in
>the HELD specification then why isn't it here?
That's not a good justification.
Further, we aren't talking about HELD, wew're talking about SIP. Use
SIP errors that already exist when using SIP. It's fine to use HELD
errors when using HELD.
> >
> >I think "xmlError" can be covered at least partly by the error
> >already in Conveyance.
>
>But these are different type of XML things. We are not talking about a
>PIDF-LO error or a SIP presence related error. Here we mean an error
>related to the filter.
>
>While it appears that this is all just XML these are different specs.
>Knowning where the error happened is useful
I'll grant you that knowing the error was in the XML filters is more
granular, but I believe those filters will be in a SIP SUBSCRIBE
request. Meaning the XML needs to be acceptable to accept the
subscription, right? (I believe the answer is yes) Given that fact,
this becomes a SIP level response that determines where the error
indication should exist *because* this is the basis for accepting or
rejecting the SUBSCRIBE.
Taking this up a higher -- what is the UAC's action you want to get
when the UAC receives this error (regardless where it is)? Do you
want the UAC to
1 - resend a new SUBSCRIBE with the same filters?
2 - resend a new SUBSCRIBE with different filters?
3 - figure out what's really wrong with the filters and send those in
a new SUBSCRIBE?
4 - not try and send a new SUBSCRIBE (i.e., give up)?
this is what I'm trying to ask that we think about (wrt what you want
the errors to cause).
> >
> >What's the difference between a "badly formed filter" and a filter
> >that's "unsupported or understood".
>
>"badly formed filter" means that there is a problem with the XML
>elements in the filter.
>This requires that you understand it to figure out whether it is badly
>formed.
ok - then how is "badly formed filter" different from "xmlError"?
You seemed to have explained both the same basic way.
>"unsupported or understood" means that you don't understand an
>extension.
What is the expected UAC reaction to receiving this error message
(regardless of where/how it receives it)? Do you want the UAC to
1 - resend a new SUBSCRIBE with the same filters (hoping the filter
recipient will understand this time)?
2 - resend a new SUBSCRIBE with different filters (by changing or
deleting the extension that wasn't understood)?
3 - figure out what's really wrong with the filters and send those in
a new SUBSCRIBE?
4 - not try and send a new SUBSCRIBE (i.e., give up)?
5 - (this is new from above) send the same filters to another entity
hoping it understands this/these filter extensions?
this is what I'm trying to ask that we think about (wrt what you want
the errors to cause).
> > What's the receiver of this error
> >to do with this distinction? I believe the reaction is to do the same
> >thing -- omit that filter and send the rest over again.
>
>That very much depends on the specific aspect. With badly formed you
>will hardly have a chance to fix it automatically.
ok - I think you used this justification in Conveyance to just drop
this error code because there's nothing positive to be done, so the
UAC can't do anything about fixing the filters so why have the error at all?
not so fun to have the shoe on the other foot, is it?
>With "unsupported or
>understood" you might be able to omit the extension if it is not so
>important for what you want to accomplish.
hmmm -- "...might be able to omit..." isn't really good guidance in a
specification, so this error really should not exist either, as it
will lead to interoperability problems with inconsistent implementations.
> > This is also
> >covered by one of the error categories in Conveyance already.
>
>SIP location conveyance should not describe errors for filters. Ideally,
>the filters document should have defined errors for that matter.
I'm working with you, except... If location filters are the reason a
SIP SUBSCRIBE request fails (from a dereference transaction), then
this is within Conveyance's scope.
>SIP Location conveyance talks about errors that the LR sends back when
>it receives something. This is a different semantic about a different
>object.
this has me thinking (be afraid!)
given that Conveyance is about Location Conveyance, and location can
be conveyed indirectly (by sending a location URI instead of a
PIDF-LO), perhaps I have the Section 4.5 message flow all wrong.
Here is Figure 4 now in Conveyance -01:
Alice Location Server Bob
| |
| INVITE w/ Location URI |
|-------------------------------------------------------->|
| | |
| 200 (OK) |
|<--------------------------------------------------------|
| | |
| | SUBSCRIBE to location URI |
| |<-----------------------------|
| | 200 (OK) |
| |----------------------------->|
| | |
| | NOTIFY w/ PIDF-LO |
| |----------------------------->|
| | 200 (OK) |
| |<-----------------------------|
| | |
Figure 4. Location-by-Reference and Dereferencing
But this lacks something you just (perhaps inadvertently) pointed
out: that the 200 OK to the INVITE means that location was received
by Bob, when in fact Bob hasn't dereferenced Alice's location yet to
know if he can get her location. In other words, Bob can't error
Alice's INVITE because of bad location information if he hasn't
received it yet, can he? The answer is no. Bob needs a means to be
able to inform Alice that there was something wrong in Bob's learning
her location. Therefore the 200 OK (or rejection) to the INVITE needs
to move down in the flow - but I'm not sure if it needs to be after
the 200 OK to the SUBSCRIBE or after the NOTIFY (which contains
Alice's location (i.e., her PIDF-LO)).
I believe the Conveyance can move Bob's response to the INVITE after
the response to the SUBSCRIBE (200 OK or an error) without
substantial delay in call set-up, but I don't know yet if moving
Bob's response to the INVITE after the NOTIFY will increase this too
much. Here's a visual of what I'm talking about with the 200 OK to
the INVITE being after the 200 OK to the SUBSCRIBE:
Alice Location Server Bob
| |
| INVITE w/ Location URI |
|-------------------------------------------------------->|
| | |
| | SUBSCRIBE to location URI |
| |<-----------------------------|
| | 200 (OK) (SUB) |
| |----------------------------->|
| | |
| 200 (OK) (INV) |
|<--------------------------------------------------------|
| | |
| | NOTIFY w/ PIDF-LO |
| |----------------------------->|
| | 200 (OK) (NOT) |
| |<-----------------------------|
| | |
(possible) Figure 4. Location-by-Reference and Dereferencing
I'll generate a new message on the SIPCORE list asking about this
timing issue to get feedback from the SIP savvy folks.
I'm glad you brought this up, Hannes - I think this is significant
wrt the dereference transaction.
> >
> >By my count, I've just shown that 5 of the 6 errors above are (or
> >their actionable categories are) already in Conveyance. Making me
> >question the need for complicated XML errors just for 1 unique error
> >code. I find it ironic that this particular error
> >"cannotProvideLiType" was bashed out of Conveyance-09 in a special
> >bar-bof on Conveyance, yet being proposed here as a good idea.
>
>For whatever reason you want to move every possible functionality into
>SIP Location Conveyance.
not so, but since you are discussing a SIP based document, why do you
want to emulate HELD in SIP - when SIP already has some of this covered?
> >
> >
> >>As an approach I would suggest to follow two principles:
> >>* keep it simple
> >
> >I agree with this
>
>But we have a disagreement of what that means.
>
> >
> >>* wait for implementers feedback to improve the quality (and then
> >>re-submit a new RFC updating the old one)
> >
> >this sounds great, but we have to start somewhere, and that appears
> >to be under contention -- specifically with the placement of the
> >error indication (in SIP or in a message body (at least)).
> >
> >
> >>Is there anyone with ideas on how we can also turn the task
> >of defining
> >>new error codes into rocket science and spread the work over many
> >>different IETF documents so that implementers get totally confused?
> >
> >interesting attitude (or was that sarcasm?)... given that this
> >Filters doc doesn't really work without Conveyance, does it?
>
>If the filters document does not work without sip location conveyance
>then we have failed.
>
> >
> >Given that error indications already exist in Conveyance, why make
> >things more complicated by introducing another set of error
> >indications that at least partially contradict those in Conveyance,
> >which are necessary.
>
>The errors do not exist in location conveyance. They are different
>errors with different semantics. You can map them in some way but I
>doubt that it makes a lot of sense.
If the errors accounted for within the filters doc can cause
location-based errors affecting SIP signaling, then a common ground
needs to be reached. Much of that work is in Conveyance now.
If, however, the errors in the filters doc do not cause SIP signaling
errors, then you are right to have them separate to Conveyance.
Can we agree to that?
> >
> >It seems appropriate that, at least, if there needs to be two places
> >for error indications (and I agree there probably are unique filter
> >based errors), that the two docs would work together - and not fight
> >each other on this.
>
>These are different errors. So, there shouldn't be a conflict between
>them at all.
>
>There is a document that defines largely how to move location to a LR.
>That's something you have to get right.
>
>Then, there is a presence event package with filters. When there is
>something wrong with the filters then that should not impact the other
>documents.
see my point just above on this
James
> >
> >That said, Conveyance has its error indications categorized into what
> >the conveyer (or subscriber) is to do with the error upon receipt of
> >it. It seems to me that within those 5 actionable responses, most or
> >all of the filter errors could be place as well - which could be
> >placed into unique specific error codes, yet still within the same 5
> >actionable categories. I think this likely will remain true for
> >errors experienced during the NOTIFY phase of location updates.
>
>I don't want to put error codes into a different document just because
>of "what" (I don't even know what would be a good argument for doing
>that).
>
>Ciao
>Hannes
>
>
> >James
> >
> >
> >>Ciao
> >>Hannes
> >>
> >>_______________________________________________
> >>Geopriv mailing list
> >>Geopriv@ietf.org
> >>https://www.ietf.org/mailman/listinfo/geopriv
> >
> >
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
