Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.txt

From: Christer Holmberg <[email-masked]>
Date: Sun, 27 Feb 2011 22:26:57 +0100

Hi,

I guess we should use RFC 6086 for INFO, as it obsoletes RFC 2976.

I guess RFC 3265 (and potentially RFC 3262) might also going to be obsoleted at some point, due to 3265bis, but I guess we don't want to wait for that.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Saturday, February 26, 2011 2:10 AM
To: James M. Polk (E-mail); SIPCORE
Subject: Re: [sipcore] I-D      Action:draft-ietf-sipcore-location-conveyance-06.txt

James,

A few things...

Section 4.1:

    Additionally, the first SIP intermediary to add a locationValue adds
    it as the last locationValue in the header value. A SIP intermediary
    that adds a locationValue MUST position it as the last locationValue
    of the last Geolocation header field of the message.

John E already called this out, and I agree.
The first sentence ("Additionally...header value.") should be removed.
The subsequent sentence covers all that and more.

(There is nothing special about the *first* intermediary to add
locationValue.)

In the same section:

    This document defines the Geolocation header field as valid in the
    following SIP requests:

       INVITE [RFC3261],             REGISTER [RFC3261],
       OPTIONS [RFC3261],            BYE [RFC3261],
       UPDATE [RFC3311],             INFO [RFC2976],
       MESSAGE [RFC3428],            REFER [RFC3515],
       SUBSCRIBE [RFC3265],          NOTIFY [RFC3265],
       PUBLISH [RFC3903],            PRACK [RFC3262]

This isn't new, and maybe it came up before (I don't recall), but was
there a reason why PRACK is in this list? I can't think of a good reason
to put Geoloc info in PRACK, and PRACK is a message that really should
not be rejected. Geoloc info provides another potential reason why a
recipient might find a need to reject it.

Unless there is some history on this point, and particular reason for
including PRACK, I propose that it be removed from the list.

Section 4.4:

    message-header          /= Geolocation-Error-header ;
                                 (message-header from 3261)
    Geolocation-Error        = "Geolocation-Error" HCOLON
                                 locationErrorValue

The name used in the two statements is not consistent. Change the first:

    message-header /= Geolocation-Error ; (message-header from 3261)

Section 8:

I don't see anything to register the Geolocation-Error header.
Did that get missed up till now?

        Thanks,
        Paul
_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Feb 2011 09:06:37 -0500

> I guess we should use RFC 6086 for INFO, as it obsoletes RFC 2976.

Which one makes no difference to this draft, but yes, it makes sense to 
reference the latest revision.

> I guess RFC 3265 (and potentially RFC 3262) might also going to be obsoleted at some point, due to 3265bis, but I guess we don't want to wait for that.

Again it makes no difference to the substance of this draft.
And in this case, referencing the bis would make a dependency, which is 
not a good thing in this case. So these refs should be left as is.

	Thanks,
	Paul

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 28 Feb 2011 13:55:17 -0600

Christer

I have no record of receiving your message, which is strange.

Anyway, I agree with you to change INFO to use RFC 6086, but I agree 
with Paul that I don't want to replace existing RFCs as references 
with their bis replacements when I'm not using the updated part of 
the new ID within my current version of my ID. Does this make sense? 
I also want to avoid any dependencies that are drafts whenever possible.

James

At 08:06 AM 2/28/2011, Paul Kyzivat wrote:

>Which one makes no difference to this draft, but yes, it makes sense 
>to reference the latest revision.
>
>>I guess RFC 3265 (and potentially RFC 3262) might also going to be 
>>obsoleted at some point, due to 3265bis, but I guess we don't want 
>>to wait for that.
>
>And in this case, referencing the bis would make a dependency, which 
>is not a good thing in this case. So these refs should be left as is.
>
>         Thanks,
>         Paul
>
>>Regards,
>>
>>Christer
>>
>>Subject: Re: [sipcore] 
>>I-D      Action:draft-ietf-sipcore-location-conveyance-06.txt
>>
>>James,
>>
>>A few things...
>>
>>Section 4.1:
>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Feb 2011 21:30:18 +0100

Hi, 

>Anyway, I agree with you to change INFO to use RFC 6086, but 
>I agree with Paul that I don't want to replace existing RFCs 
>as references with their bis replacements when I'm not using 
>the updated part of the new ID within my current version of 
>my ID. Does this make sense? 

Yes. My suggestion was not that we should add a reference to a bis draft, or to wait until the bis draft becomes an RFC. It was to make people aware, in case someone would be aware of some impacts. But, as Paul said, from a technical perspective it probably doesn't matter in this case.

Regards,

Christer

> >>obsoleted at some point, due to 3265bis, but I guess we 
> don't want to 
> >>wait for that.
> >
> >>From: [email-masked] [[email-masked]] 
> On Behalf Of 
> >>Paul Kyzivat [[email-masked]]
> >>there a reason why PRACK is in this list? I can't think of a good 
> >>reason to put Geoloc info in PRACK, and PRACK is a message 
> that really 
> >>should not be rejected. Geoloc info provides another 
> potential reason 
> >>why a recipient might find a need to reject it.
> >>