headers
Jonathan Rosenberg | 1 Mar 2006 03:03
Picon
Favicon

Re: I-D ACTION:draft-akhtar-sipping-header-reduction-00.txt

Its not clear from reading this document why everything in here cannot 
be accomplished with sigcomp alone. The basic idea, if I understand 
right, is that, upon registration, the proxy server stores certain 
information about the UA which is not expected to change from request to 
request, and it repopulates it when a UA emits a request (which won't 
contain that information). That is more or less equivalent to placing 
that information into a sigcomp dictionary and then using sigcomp to ask 
the server to extract the information from the dictionary.

Thanks,
Jonathan R.

Internet-Drafts <at> ietf.org wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: New SIP Headers for Reducing SIP Message Size 
> 	Author(s)	: H. Akhtar, et al.
> 	Filename	: draft-akhtar-sipping-header-reduction-00.txt
> 	Pages		: 18
> 	Date		: 2006-2-28
> 	
>    Current SIP messages are text based and inherently large, especially
>    when these messages are to be transmitted over the bandwidth-strained
>    wireless access technologies (a typical orginiating SIP Invite is 
>    about 1200 bytes). 
> 
>    For most wireless technologies, transmitting the session initiation 
>    messages (such as SIP Invite) over the signaling channel can reduce
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miguel Garcia | 1 Mar 2006 08:17
Picon

Re: Questions about FTP protocol implementation on a SIP session

Dean Willis wrote:
> 
> On Feb 24, 2006, at 7:14 PM, Benoît Werion wrote:
> 
>> First my question is  : is it possible to do it? Let me explain, I 
>> would like to add the possibility of transferring a file on the FTP 
>> protocol in parallel with an RTP stream established by SIP.
>>
>>
>> Benoît Werion
> 
> See:
> 
> http://www.ietf.org/internet-drafts/draft-isomaki-sipping-file-transfer-00.txt 
> 
> 
> 
> -- 
> Dean
> 

The draft Dean pointed out contains requirements. A possible solution 
has been recently submitted in this other draft:

http://www.ietf.org/internet-drafts/draft-garcia-sipping-file-transfer-mech-00.txt

Note that the draft proposes to use MSRP as the protocol for file 
transfer, rather than FTP.

/Miguel
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miguel Garcia | 1 Mar 2006 08:59
Picon

Re: MUSTs and SHOULDs [was RE: new draft on overload control in SIP]

Dean Willis wrote:
> 
> 
> Bad example from draft-ietf-sipping-uri-list-message-05.txt:
> 
>    A UAC that wants to create a multiple-recipient MESSAGE request MUST
>    create a MESSAGE request according to RFC 3428 [8] Section 4.  The
>    UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the
>    MESSAGE URI-list service.  In addition to the regular instant message
>    body, the UAC SHOULD add a URI-list body whose Content-Disposition
>    type is 'recipient-list', specifed in the Framework and Security
>    Considerations for SIP URI-list Services [11].  This body contains a
>    URI-list with the recipients of the MESSAGE.  The URI-list body MAY
>    also include the 'capacity' extension to the URI-list specified in
>    Section 4.1.  The UAC MUST also include the 'recipient-list-message'
>    option-tag, defined in Section 5, in a Require header field.
> 
> 
> Let's look at the "requirements" in the above.
> 
> MUST #1 (create a message request): Why MUST we create a message 
> request? What failure of interoperability occurs if we don't create a 
> message request? We're really trying to say that this service only 
> understands MESSAGE requests as defined in RFC 3428, and that it won't 
> work if you were to use some other kind of request.

The intention in that text is to "import" Section 4 of RFC 3428, which 
is extremely important in this case. Please read such section and tell 
me which normative text we shouldn't import. If we fail to normatively 
refer to Section 4 of RFC 3428, some major implementor who wouldn't care
(Continue reading)

Permalink | Reply | 4 comments |
headers
Aki Niemi | 1 Mar 2006 11:10
Picon

Re: MUSTs and SHOULDs [was RE: new draft on overload control in SIP]


ext Dean Willis wrote:
> What's the Finnish word for idiot, anyhow? I'm sure I've overheard it in
> some of those standards discussions after I've said something
> "controversial", but it would be nice to know. One can never know too
> many insults, they're such handy words.

It's "idiootti", "idiootit" in plural.

But we never use that, because it's too close to English. Instead, we
usually exclaim "ääliö", "tollo", "taukki", "hölmöläinen", or plain
simple "tyhmä". With a smile on our face, of course.

;-)

Cheers,
Aki

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 1 comment |
headers
Pete Cordell | 1 Mar 2006 11:13

Re: MUSTs and SHOULDs [was RE: new draft on overload controlin SIP]

----- Original Message From: "Miguel Garcia" <Miguel.An.Garcia <at> nokia.com>
>
> True, but as you mention, we expect the reader to familiar with SIP and
> the Require header. I don't think this draft is a SIP tutorial.

I agree with Miguel here - too much tutorial material can make it harder for
the more experienced developer to read, and eventually even the beginner
will become experienced and thank you in the long run for omitting tutorial
material!  That said with all the documents that make up SIP, a little
guidance to novices would be helpful.  For that a simple reference should
suffice, along the lines of:

    ...Section 4.1.  The UAC MUST also include the 'recipient-list-message'
    option-tag, defined in Section 5, in a Require header field (RFC 3261
    [5] Section 8.2.2.3).

It would be even better if the referencing mechanism could be made more
specific so that you get something of the form:

    ...Section 4.1.  The UAC MUST also include the 'recipient-list-message'
    option-tag, defined in Section 5, in a Require header field [5:8.2.2.3].

e.g. a references ABNF becomes:

    ref = '[' doc-id [ ':' section-number ] ']'
    doc-id = 1*DIGIT
    section-number = 1*DIGIT  *( '.' 1*DIGIT )

Alternatively, you could define special references that are primarily
intended to aid novices only.  For example, you could include text of the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Spencer Dawkins | 1 Mar 2006 14:36
Favicon

Re: MUSTs and SHOULDs [was RE: new draft onoverload controlin SIP]

Falling off-topic for SIPPING, except that the SIP community seems to need 
this facility more than most...

From: "Pete Cordell" <pete <at> tech-know-ware.com>

> I agree with Miguel here - too much tutorial material can make it harder 
> for
> the more experienced developer to read, and eventually even the beginner
> will become experienced and thank you in the long run for omitting 
> tutorial
> material!  That said with all the documents that make up SIP, a little
> guidance to novices would be helpful.  For that a simple reference should
> suffice, along the lines of:
>
>    ...Section 4.1.  The UAC MUST also include the 'recipient-list-message'
>    option-tag, defined in Section 5, in a Require header field (RFC 3261
>    [5] Section 8.2.2.3).
>
> It would be even better if the referencing mechanism could be made more
> specific so that you get something of the form:
>
>    ...Section 4.1.  The UAC MUST also include the 'recipient-list-message'
>    option-tag, defined in Section 5, in a Require header field 
> [5:8.2.2.3].

Having recently reviewed an Internet Draft with a reference that said, "see 
RFC 1122" with no indication which of the 116 excellent pages might be 
helpful, I can only agree :-)

Thanks,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dale R. Worley | 1 Mar 2006 16:03

Re: MUSTs and SHOULDs [was RE: new draft on overload control in SIP]

On Wed, 2006-03-01 at 12:10 +0200, Aki Niemi wrote:
> ext Dean Willis wrote:
> > What's the Finnish word for idiot, anyhow? I'm sure I've overheard it in
> > some of those standards discussions after I've said something
> > "controversial", but it would be nice to know. One can never know too
> > many insults, they're such handy words.
> 
> It's "idiootti", "idiootit" in plural.
> 
> But we never use that, because it's too close to English. Instead, we
> usually exclaim "ääliö", "tollo", "taukki", "hölmöläinen", or plain
> simple "tyhmä". With a smile on our face, of course.
> 
> ;-)

I'm glad to see that Finnish has such careful shades of meaning in this
domain.

Hmmm, it reminds me of the joke, "Just as the Eskimo language has 27
words for various types of snow, Yiddish has 100 ways to call someone an
idiot."

Perhaps this is an area in which standardization is needed?  ;-)

Dale

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Willis | 1 Mar 2006 17:21
Favicon

Re: MUSTs and SHOULDs [was RE: new draft on overload control in SIP]

Miguel Garcia wrote:
> Dean Willis wrote:
> 
>>
>>
>> Bad example from draft-ietf-sipping-uri-list-message-05.txt:
>>
>>    A UAC that wants to create a multiple-recipient MESSAGE request MUST
>>    create a MESSAGE request according to RFC 3428 [8] Section 4.  The
>>    UAC SHOULD populate the Request-URI with the SIP or SIPS URI of the
>>    MESSAGE URI-list service.  In addition to the regular instant message
>>    body, the UAC SHOULD add a URI-list body whose Content-Disposition
>>    type is 'recipient-list', specifed in the Framework and Security
>>    Considerations for SIP URI-list Services [11].  This body contains a
>>    URI-list with the recipients of the MESSAGE.  The URI-list body MAY
>>    also include the 'capacity' extension to the URI-list specified in
>>    Section 4.1.  The UAC MUST also include the 'recipient-list-message'
>>    option-tag, defined in Section 5, in a Require header field.
>>
>>
>> Let's look at the "requirements" in the above.
>>
>> MUST #1 (create a message request): Why MUST we create a message 
>> request? What failure of interoperability occurs if we don't create a 
>> message request? We're really trying to say that this service only 
>> understands MESSAGE requests as defined in RFC 3428, and that it won't 
>> work if you were to use some other kind of request.
> 
> 
> The intention in that text is to "import" Section 4 of RFC 3428, which
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Sparks | 1 Mar 2006 17:42
Favicon

Reminder: WG item : dialog-usage

We've taken on documenting the issues around having multiple dialog  
usages share a dialog as a working group item.

draft-ietf-sipping-dialog-usage-00.txt is the current draft  
addressing that item.

I believe it to be essentially done and will ask the chairs to last  
call the document as soon as I re-verify coverage
of the response codes.

If you have not read this document, now would be a good time.

Thanks!

RjS

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 5 comments |
headers
Cullen Jennings | 1 Mar 2006 18:30
Picon
Favicon
Gravatar

Re: Re: [Sip] Thoughts on the Principle ofDividingandConquering

On 2/27/06 7:58 PM, "Paul Kyzivat" <pkyzivat <at> cisco.com> wrote:

>> Do you think we could get a bunch of people in RAI to all agree to review 2
>> drafts a month?
> 
> I would think so. I know I have been buried in other work and have been
> ignoring most drafts this cycle - much more than before. But I am sure I
> could promise to look at a few a month.

Well, I got one yes :-) I note this is from the guy that provides more
comments and answers than anyone else on the list. Thanks you Paul and keep
up the great stream of comments.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
Permalink | Reply | 0 comments |

Gmane