Subject: RE: [Sip] RE: Contact header in PUBLISH

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 10 Dec 2003 14:49:46 -0000

But Paul's text does not disallow, it says SHOULD NOT, not MUST NOT, so all recipients must cater for its inclusion, even if they have no use for it.

regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: 10 December 2003 14:31
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [Sip] RE: Contact header in PUBLISH
> 
> 
> 
> 
> > -----Original Message-----
> > From: ext Drage, Keith (Keith) [mailto:[email-masked]]
> > Sent: 10.December.2003 13:39
> > To: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki);
> > [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Sip] RE: Contact header in PUBLISH
> > 
> > 
> > If we identify another usage for this header in the future, 
> > then presumably we need to write another RFC to do it 
> > superceding the current PUBLISH RFC either fully or in part.
> > 
> > The question we therefore need to ask is whether either text 
> > has compatibility problems with such a future extension, and 
> > I believe the answer is no.
> 
> If one RFC disallows something and an extension to it allows 
> the exact same thing that is disallowed, then we have a 
> problem. If something is disallowed, it should stay that way, 
> even in extensions.
> 
> > 
> > I therefore prefer Paul's text, as it leaves fewer unanswered 
> > questions as to whether I put it in now or not. As regards 
> > Hisham's current text, I am left with the question of whether 
> > I should put it in just in case.
> 
> My text (well, Aki's) is clear, you may put contact-header, 
> but it doesn't buy you anything. Common sense will tell 
> someone not to include it. Even if you include it, so what?
> 
> Regards,
> Hisham
> 
> > 
> > regards
> > 
> > Keith
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> [mailto:[email-masked]]
> > > Sent: 10 December 2003 11:32
> > > To: [email-masked]; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: [Sip] RE: Contact header in PUBLISH
> > > 
> > > 
> > > You never know what us geniuses might come up with in the 
> > > future as a possible use for contact-header in PUBLISH. why 
> > > eliminate this possibility. Including a contact- header in 
> > > PUBLISH does not break the protocol, so no need to explicitly 
> > > disallow it. I vote for Aki's original suggestion of using 
> > > MAY with a slight modification:
> > > 
> > > 	PUBLISH request MAY include a Contact header field, 
> > > although doing so
> > > 	has no meaning in the PUBLISH context **as defined in 
> > > this specification**.
> > > 
> > > Regards,
> > > Hisham
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]]On Behalf 
> > > > Of ext Aki
> > > > Niemi
> > > > Sent: 09.December.2003 18:49
> > > > To: ext Paul Kyzivat
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: Re: [Sip] RE: Contact header in PUBLISH
> > > > 
> > > > 
> > > > 
> > > > 
> > > > ext Paul Kyzivat wrote:
> > > > > [email-masked] wrote:
> > > > > 
> > > > >>
> > > > >> PUBLISH is generally never sent in the "other" direction, 
> > > > so I don't 
> > > > >> see any reason not to say:
> > > > >>
> > > > >>     PUBLISH request MAY include a Contact header field, 
> > > > although doing so
> > > > >>     has no meaning in the PUBLISH context.
> > > > >>
> > > > >> Any other opinions?
> > > > > 
> > > > > 
> > > > > How about another phrasing that says the same thing but 
> > > > emphasizes the 
> > > > > desired behavior?
> > > > > 
> > > > >        PUBLISH request SHOULD NOT include a Contact 
> > header field.
> > > > >        Including one has no meaning in the PUBLISH context.
> > > > 
> > > > I'm OK with that, although my understanding is that if we 
> > > use SHOULD 
> > > > NOT, we should be attaching some description of the 
> > > > circumstances where 
> > > > it would be OK to include it.
> > > > 
> > > > Cheers,
> > > > Aki
> > > > 
> > > > > 
> > > > > Paul
> > > > > 
> > > > 
> > > > _______________________________________________
> > > > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > > > This list is for NEW development of the core SIP Protocol
> > > > Use [email-masked] for questions on 
> current sip
> > > > Use [email-masked] 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-masked] for questions on current sip
> > > Use [email-masked] 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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 10 Dec 2003 14:14:10 -0600

> But Paul's text does not disallow, it says SHOULD NOT, not 
> MUST NOT, so all recipients must cater for its inclusion, 
> even if they have no use for it.

"Be liberal in what you accept, and conservative in what you send" -- Jon
Postel

Personally, I prefer for people who have no interest in what I'm saying to
politely ignore me rather than confrontationally reject me. That's why I
chair working groups in the IETF.

--
Dean