At 01:27 PM 11/22/2007, Hannes Tschofenig wrote:
RFC 2119 language aims to accomplish interoperability.
The MUST NOT in that sentence does not accomplish interoperability.
which is one of my main points
It does not do harm for the proxy to still read it.
I'm sure not everyone agrees with this
I would be fine with a sentence that indicates that it is not useful
for the proxy to read the location information if the recipient
parameter is set to "endpoint".
I have no problems writing this into the doc, if this is agreeable.
Should something like, "and a LbyR URI (MUST NOT/SHOULD NOT) to be
dereferenced"
Ciao
Hannes
daniel grotti wrote:
Hi all,
so why don't emphasize this point in the next draft, saying :
"Proxy server MUST not read messages with "recipient=endpoint"
paramenter setted".
This is my point of you.
What do you think? James?
Regards,
Daniel
----------------------------------
Daniel Grotti
D.E.I.S. - University of Bologna
----------------------------------
Via Venezia, 52
47023 Cesena (FC) - ITALY
----------------------------------
e-mail: [EMAIL PROTECTED]
----------------------------------
-----Messaggio originale-----
Da: Hannes Tschofenig [mailto:[EMAIL PROTECTED]
Inviato: gio 22/11/2007 18.35
A: daniel grotti
Cc: Ted Hardie; James M. Polk; IETF SIP List
Oggetto: Re: R: [Sip] a question about IETF draft location conveyance 09
Hi Daniel,
daniel grotti wrote:
I believe that if a UA puts "recipient=routing-entity" paramenter
into locationValue, the location information should be read only
by Proxy Server for location-based routing. But if a UA wants its
own location information to be known and seen by endusers, then UA
have to insert the "recipient=endpoints" paramenter. In this case
Proxy server, from my view, should only forward the message to the
destination. UA would just like to bring its own location to an
endpoint, and could not interested in location-based routing.
Does this make sense?
Correct and makes sense.
The recipient parameter is just a hint for processing. It does not
have security properties.
Ciao
Hannes
Regards,
Daniel
-----------------------------
Daniel Grotti
DEIS - Universita' di Bologna
-----------------------------
Via Venezia, 52
47023 Cesena (FC) - ITALY
-----------------------------
email:[EMAIL PROTECTED]
-----------------------------
-----Messaggio originale-----
Da: Ted Hardie [mailto:[EMAIL PROTECTED]
Inviato: gio 11/22/2007 12:36
A: James M. Polk; daniel grotti; IETF SIP List
Oggetto: Re: [Sip] a question about IETF draft location conveyance 09
At 4:18 PM -0600 11/21/07, James M. Polk wrote:
\
Ted -- This header parameter is for a PIDF-LO, yes -- but it
pertains to the SIP WG's expertise in knowing and agreeing with
SIP's ability to foresee the type of topology from UAC to UAS,
and each server (whether there even is one) in between. I'm not
so sure the SIP WG agrees that a UAC can make this determination,
and am soliciting their input here in a broad way.
Can a UAC understand enough about the topology of the Internet to
understand where it is sending a request, including how SIP
servers may or may not act upon that request?
I believe, if the answer is no, the the "recipient=" parameter is
a flawed SIP header parameter.
If the answer is yes, then it stays with no further arguments from me.
I think we have fundamentally different ideas of how much
understanding of the
topology this implies. My view is that the header as currently
specified says
either "This is meant for the person answering the call/taking the
session" or
"This is meant to help get the call through/get the session to the
right responder".
Within the latter case, it requires no knowledge at all of topology; it does
not distinguish among the many different routing elements which might be
trying to make that happen.
A UA that does not care whether it is used for routing can enter "both"
and all is well. A UA that *wants* it to be used this way can
enter "routing-entity".
The availability of "endpoint" as a separate possibility makes sure that
an endpoint can indicate that use by the routing system is not
intended. If the SIP community believes "routing-entity" is too vague
and needs to be broken out, I do not see how the GeoPRIV could object or
why it would want to; certainly this working group should have the
final word
on that. But collapsing things so that entering "endpoint" is
not an indicator to the routing entities that they should just
pass things along
would find opposition (at the very least from me). That would
break a pretty
fundamental assumption that users are in control of the pidf-lo
distributions.
Hope you have a great Thanksgiving,
Ted
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] 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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
