Hi Ted,
At 2:32 AM +0200 4/27/07, Drage, Keith \(Keith\) wrote:I would imagine that at least Section 6 "Special Considerations for Emergency Calls" would go away.
(As SIP WG chair)
During the review of the WGLC comments, we have identified some issues where we need consensus calls on the list. These are in one call per message.
There is an amount of text (primarily section 6) within
draft-ietf-sip-location-conveyance related to emergency calls. It is
proposed to remove this text on the basis that there are charter items
within the IETF ECRIT working group that fully specify this application
of location conveyance to this particular purpose. The editor's will
make sure that all the removed text is reflected in appropriately in the
concerned ECRIT documents.
I don't think we can answer this question without the actual bits to
be removed. Can you cite in more detail?
I'd also like to point out that section 6 has a number of elements where the baseline assumption of SIP and ECRIT may differ. This, for example:
Thus S/MIME protection of location MUST NOT be used. TLS protection of location SHOULD be used, however, if establishment of the TLS connection fails, the call set-up operation, including location conveyance, MUST be retried without TLS.
The context in SIP and the larger document here makes it clear that "S/MIME protection of location" means encrypting the location, rather than signing it. But location signing is a topic of interest to ECRIT, and the resulting baseline assumptions may be different. Increased clarity on exactly what is meant will hopefully result, but remember this will end up in some document with a bunch of other context to it.
I also believe that this section:
Both the "retransmission-allowed" and "routing-query-allowed" SHOULD be set to "yes". Querying for routing may be performed by proxies providing a routing service for emergency calls even if retransmission-allowed or routing-query-allowed is set to "no" or is not present. Proxies routing on the location MUST set the "message-routed-on-this-uri" parameter.
would have to be substantially re-written to fit into phonebcp (presuming that is where it lands). To make sense there, I believe it would have to repeat context from location-conveyance (even with the existing normative reference). That's always an invitation to things getting out of synch in the future, and has to be considered.
Put another way, I don't think you're going to be able to just shift
the text en masse and be done.
Ciao Hannes
regards, Ted
We will assume that this removal represents WG consensus unless we hear otherwise from the WG in 7 calendar days from the posting of this message.
Regards
Keith
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip