Hadriel,
Is the problem that the document is hard to implement? Or just that you
think it has too many words?
IMO when we leave ambiguity there will be problems.
I would rather see more words than have a brief but ambiguous document.
More words do not (necessarily) make the implementation more difficult.
Making the wrong choice of words can complicate the implementation.
Its also the case that we end up using a lot more words (in emails)
along the way to convince ourselves that we all agree on what is meant.
Once we agree, it may not take so many words in the document to
unambiguously specify what we have decided.
We know we have needs for multipart, for things like Geoloc, and
probably more, that are orthogonal to other usages. We are headed for a
train wreck on that because 3261 didn't say enough about that. The body
handlng draft will hopefully address much of that. We just need to try
to ensure that other things play well with that.
Thanks,
Paul
Hadriel Kaplan wrote:
I think we're just going 'round and 'round on basically a non-issue.
Making *any* changes to INFO which don't provide real, tangible, and immediate
value to either the developer or the customer/user, does not bode itself well
to getting implementation. Because INFO works.
Having a negotiation/detection scheme provides real, immediate value, by
avoiding/reducing configuration.
Having a sub-context for the context already created by the "INFO" method does
*not* provide such value, because there are no collisions/confusion in the real world
AFAIK; but it was a common complaint from the IETF, so we put the Info-Package header in
to resolve that. It can basically be handled as syntactic sugar by current
implementations, and is similar to Sub/Not/Pub, so fine.
Then somehow between IETF Dublin and Minneapolis, a mere 3.5 months (but a
world apart in Guinness flavor), the draft doubled in size, adding another 20
pages. To do what? To add more dis-ambiguation and contextualizing, for a
problem that has never actually been seen in the wild?? How many contexts of
contexts, and meanings of meanings, do we need? What value does that add over
the currently deployed INFO?
-hadriel
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 03, 2008 3:39 PM
To: Christer Holmberg
Cc: Hadriel Kaplan; Dean Willis; SIP List
Subject: Re: [Sip] Multiple body-parts in one INFO
Christer Holmberg wrote:
Hi,
- CID is too complex, and I think it will prevent some people from
moving from legacy to info packages.
- "Render" as the c-d is probably not 100% waterproof, since other body
types may also use it.
- I DO still strongly support a new c-d for the package body, but it
seems that others have issues with that.
How is CID "too complex"??? The id can be hard coded in most cases. So
its just some additional boiler plate to add into the request. And it
adds *1* extra header to the message. Anybody who can't manage that
shouldn't be sending SIP messages.
I do think that a *new* c-d would be clearer than reusing "render".
I guess my preferences (1-100, 1 best) are:
1) new c-d
2) cid
10) c-d "render"
100) single c-t for info-packages.
Paul
_______________________________________________
Sip mailing list https://www.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://www.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
