~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 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?
>
>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
>
>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.
"unsupported or understood" means that you don't understand an
extension.
> 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. With "unsupported or
understood" you might be able to omit the extension if it is not so
important for what you want to accomplish.
> 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.
SIP Location conveyance talks about errors that the LR sends back when
it receives something. This is a different semantic about a different
object.
>
>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.
>
>
>>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.
>
>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.
>
>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
