Hi Peter,
thanks for the comments, see answers in line
best regards
Sal
Leis, Peter (NSN - DE/Munich) wrote:
hello,
some comments on your draft.
on 4.1 Referrer Behaviour
this clause is called Referrer Behaviour. However, in the context of
RFC3892, the Referrer is the entitiy sending out a REFER request. Later
on you seem to speak of a different entity (exploder server). So the
title of this clause should change to something like "Referred-By
handling"
[Sal] yes, you are right, in the next version we will change the title
as you proposed in "Referred-by handling"
In addition, I believe, you could also cover the case, where a Referrer
does include Referred-by in the RERFER request and wants to include more
than one SIP URI in the Referred-By header field. I guess this should be
possible using your draft.
[Sal] well we are extending the Referred-By header definition to support
more than one SIP URI,
so yes it would be possible for a user to insert in the Referred-by
header of a REFER request more
then one SIP URI.
I don't know if it is necessary to explicit it. what do you think?
Would be good to be more specific as to what "if privacy was requested"
means. Something like "if privacy was request using a Privacy header
field with value 'id' "
[Sal] we will reword the statement to be more specific here.
on 4.2 "General handling"
the title of this clause could be more specific. Although being called
"general", you seem to describe handling of "unexpected cases"
[Sal] That's a correct observation, this section handles error cases
when more than one URI is received
so we will change the title to "Hanlding of unexepected cases".
regards
Peter
-----Original Message-----
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On
Behalf Of ext Salvatore Loreto
Sent: Monday, March 02, 2009 10:12 AM
To: sipping
Cc: Nadia Bishai; Adamu.Haruna@xxxxxxxxx
Subject: new draft version to extend Referred-By
Hi there,
I have just submitted a new version of the draft
http://www.ietf.org/internet-drafts/draft-loreto-sipping-3892bis-01.txt
it explains the needs for the
Referred-By header to be extended to to support more than one value:
In fact as explained in the draft the Referred-by header is normally set
to the value contained
in the P-Asserted-Identity header field to convey to the receiver the
identity of the original
inviting sender.
However the P-Asserted header field currently allows two URI values and
may be expanded in the future to carry more than two values as described
in :
http://tools.ietf.org/id/draft-ietf-sipping-update-pai-09.txt
cheers
Sal
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP
